Unified geographic database and method of creating, maintaining and using the same

ABSTRACT

The present invention involves a Universal Geographic Database (“UGD”). The UGD is an automated, central or distributed, registry of real-world locations and location-related information for businesses and other entities, analogous to the registry of domain names for Internet and web sites. By this central registry, businesses and other entities are facilitated to post their location and location-related information in a single place, for all users who need or want it; and users can refer to this single place, via the Internet, Web, and other telecommunications devices, to obtain accurate, complete and timely location and location-based information about the registered businesses and other entities. Each record of the UGD is keyed by a proprietary location address (PLA) based on the World (Geographic Referencing System (WGRS), and optionally may have one or more proprietary location addresses (PLAs), which also may serve as keys. Associated with the PLA keys, each UGD record generally includes the full name for the business or other entity, its street address, and miscellaneous contact information (e.g., telephone number, facsimile number, e-mail address, internet website address, wireless website address). Other more dynamic, customized information (e.g., store hours, credit cards accepted, inventory, prices, specials, hours, parking) also may be available in the UGD record or linked to the UGD record. Users of any device or service can access the UGD through one or more location name servers (LNS), which can provide access to the UGD or other location-based information linked to the UGD or LNS. Based on the WGRS, PLAs provide, in addition to unique keys for UGD records, a user-friendly notation for location naming in the real-world and on all types of location-sensitive electronic devices, from web phones to in-car navigation systems. Given the UGD, these ULA/PLAs are as important to real-world businesses as their domain names because these WGRS addresses drive real-world commerce to physical business locations just as domain names drive e-commerce Internet or web sites.

RELATED APPLICATIONS

[0001] This application is a continuation-in-part of U.S. patentapplication Ser. No. 09/257,462, filed Feb. 25, 1999, now pending, whichis a continuation-in-part of U.S. patent application Ser. No.09/188,153, filed Nov. 4, 1998, now U.S. Pat. No. 6,047,236, which is acontinuation of U.S. patent application Ser. No. 08/701,586, filed Aug.22, 1996, now U.S. Pat. No. 5,839,088. The above referenced patents andpatent applications are incorporated herein by reference as if set forthin full.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] The present invention relates to a Unified Geographic Database(“UGD”), and methods of creating, acquiring, managing, maintaining,using and distributing location-based information through bothcentralized and distributed databases referred to as a Location NameServers. The Location Name Servers are accessible through a variety ofdevices and computer systems, including the Internet, communicationsnetworks and gateways and other telecommunications channels.

[0004] 2. Background and Related Art

[0005] Countless sources of information exist to assist people who needinformation concerning the location and practices of real-worldbusinesses and other private and public entities. This information isvery actively used by people engaged in the business process: findinglocations, obtaining maps and directions, hours of operation, inventory,prices, etc., generally to assist in shopping and purchasing decisions.Notwithstanding the power of the Internet as a means of gathering anddisseminating information, there is currently no universal“clearinghouse” method or system of acquiring and distributinglocation-based basic, enhanced and/or real-time information about themillions of real-world businesses and other addresses in the world.Rather, the location-related information is currently stored inliterally millions of databases throughout the world, including personaland corporate rolodexes, accounting master files, and especiallytelephone-directory databases. These disparate sources are continuallyin flux, but on different schedules, and often materially inaccurate inone way or another. No single source exists to provide or link tocorrect, up-to-date information regarding all businesses and otherentities. Further, it is impossible currently to synthesize the manysources of information on a timely basis, and also to distribute it tothe myriad systems where it is needed and used.

[0006] The largest single source of location-based information regardingbusinesses is that of Yellow Page publishers. Still, Yellow Pagespublishers, whether via physical books or the Internet, do not possesslistings of all locations, e.g. city parks. In practice, the majority oflocation-based information on business and individual addressinformation is derived from the local telephone exchange carrier(“LEC”). Historically there has only been one LEC for any given regionor area. Nevertheless, it is clearly not the LEC's primary business tocreate and distribute address and location information. In addition,many businesses now use competitive local exchange carriers (a “CLEC”),so there is not one clear source for local business telephone listings.Some individuals, and a few businesses, are foregoing wireline telephoneservice entirely, which means that the addresses may never be capturedin the LEC or CLEC system. Furthermore, LECs and CLECs typically onlyobtain basic information such as name, street address and telephonenumber. These street addresses may or may not be geocoded (throughvarious geocoding engines, with uneven results), so that their actualposition in space, and on maps is unreliable. Enhanced information istypically obtained by Yellow Page providers, but this information rarelymakes it into any type of universal, location-based database designed toprovide immediate access to all users of Internet-enabled devices andservices. Finally, the LEC and CLEC information is not updated quicklyor, with changes in carriers, even regularly: Yellow-Page books aretypically printed annually, and, thus, provide an incredibly inefficientmethod of address and location handling that ultimately takes littleadvantage of the power of the Internet.

[0007] Accordingly, large amounts of resources, including time,personnel and money, are currently being wasted on (1) multiplesolicitations of the same information from the same businesses and (2)storage and distribution of that information. Users, too, waste timeconducting multiple searches for the same information, seekingconfirmation of information from more than one source as an estimate ofits accuracy, i.e., to avoid driving some distance to a store which nolonger exists or which no longer carries a desired product.

SUMMARY OF THE INVENTION

[0008] Accordingly, an aspect of the invention involves a UnifiedGeographic Database (“UGD”). The UGD is a database registry for thelocations and location-related information of real-world businesses andother entities, analogous to the registry of domain names for Internetand web sites. Via this registry, businesses and other entities canimmediately post their location-related information to make it availableto potential users; and users can simultaneously query this registry toobtain accurate, complete and timely location-based information aboutthese businesses and other entities, via Internet-connected electronicdevices or services. Each record of the UGD includes a unique,user-friendly, domain-name like hierarchical geographical referencingaddress (based on the World Geographic Referencing System (WGRS)) thatcan serve as a discrete identifier, the business or other entity name,its street address, and basic contact information (e.g., telephonenumber, facsimile number, e-mail address, internet website address,wireless website address). Other, more detailed but fairly static yetcustomized information (e.g., store hours, credit cards accepted, majorbrands carried, hours or operation, specific parking alternatives, etc.)may also be available in the record. Ultimately, extremely customized,real-time information (e.g., inventory availability in particularmodels, sizes or colors; the availability of unique, short-termgeographically restricted specials, discounts, coupons and otherpromotions, etc.) can be linked to the discrete identifier anddistributed directly to end-users or through third-parties seeking todistribute such location-based information. The unique, user-friendlygeographical referencing address is as important to real-worldbusinesses as their domain name because this unique address drivesreal-world commerce at the business location instead of e-commerce at awebsite. Not only does this unique address provide the discreteidentifier for the UGD record, it is designed to provide a user-friendlynaming convention and interface for all types of electronic devices-fromweb phones to car navigation systems.

[0009] An additional aspect of the invention involves a method ofcreating a UGD by registering a proprietary name for a geographicallocation of an entity. The method includes receiving geographicallocation information for an entity, receiving a proprietary name for theentity, geocoding the geographical location information into ahierarchical address, and storing the proprietary name, hierarchicaladdress, and geographical location information as a record in the UGD.

[0010] Another aspect of the invention involves a method of creating aUGD by registering a proprietary name for a geographical location of anentity. The method includes receiving geographical location informationfor an entity, receiving a proprietary name for the entity, and storingthe proprietary name and geographical location information for theentity as a record in the UGD.

[0011] A further aspect of the invention involves a method of creating aUGD by registering a universal location address (ULA) for a geographicallocation of an entity. The method includes receiving geographicallocation information for an entity, geocoding the geographical locationinformation into a ULA based on the WGRS, and storing the ULA andgeographical location information as a record in the UGD.

[0012] An additional aspect of the invention involves a method of usinga UGD containing records for multiple entities referenced by a WGRSaddress and returning location-related information for the entities. Themethod includes receiving a WGRS address, accessing one or more entityUGD records based on the WGRS address, and providing location-relatedinformation from the one or more entity UGD records accessed.

[0013] Another aspect of the invention involves a UGD comprising recordsfor multiple entities, each entity record including a WGRS domain-name,like hierarchical address associated with location-related informationfor an entity.

[0014] A further aspect of the invention involves a Location Name Server(LNS) to facilitate convenient and ubiquitous access to the UGD. Via oneor more LNSs, users of connected devices can query the UGD for detailedlocation-based information according to both spatial and aspatialattributes which they may (partially) know, e.g. business name, streetaddress, registered brands, etc. Particularly useful types of spatialattributes also supported in LNS queries are Universal LocationAddresses (ULAs) and Proprietary Location Addresses (PLAs), describedbelow, which provide a user-friendly georeferencing notation forreal-world locations based on the WGRS specification.

[0015] A still further aspect of the invention involves a Location NameServer for use with a UGD having records for multiple entities, eachentity record including a WGRS domain-name, like hierarchical addressassociated with location-related information for an entity. The LocationName Server includes a geocoding conversion engine for converting astreet address or latitude/longitude coordinates to a WGRS address foraccessing an entity UGD record based on the WGRS address, and convertinga WGRS address to a street address or latitude/longitude coordinates.

[0016] Further features and advantages of the invention, as well as thestructure and operation of various embodiments of the invention, aredescribed in detail below with reference to the accompanying drawings.

BRIEF DESCRIPTIONS OF THE DRAWINGS

[0017] The drawings illustrate the design and utility of preferredembodiments of the present invention, in which:

[0018]FIG. 1 shows two overlapping districts, each with a referencepoint and a grid system.

[0019]FIG. 2 shows a single cell of FIG. 1 with hierarchical gridding toincrease the addressing resolution.

[0020]FIG. 3 is a functional diagram of a preferred embodiment of theinvention.

[0021]FIG. 4 shows how proprietary locational names are compiled anddistributed.

[0022]FIG. 5 is a diagram of a navigational system incorporating one ormore aspects of the subject invention.

[0023]FIGS. 6 and 7 show the use of PLAs and ULAs in a specificgeographical context.

[0024]FIGS. 8a-8 b, 9, 10 a-10 c, 11 are examples of specific files usedin one implementation of the subject invention.

[0025]FIGS. 12a-12 c are examples of screen outputs used in oneimplementation of the subject invention.

[0026]FIG. 13 depicts an operational environment of the automaticlocation aspect of the present according to a preferred embodiment.

[0027]FIG. 14 is a block diagram depicting details of theportable-computing device in accordance with the subject invention.

[0028]FIG. 15 is a block diagram depicting functional components of anapplication program or program(s) running on the portable-computingdevice in accordance with an embodiment of the present invention.

[0029]FIG. 16 is a flowchart that generally describes an overall processin accordance with an embodiment of the present invention.

[0030]FIG. 17 is a flowchart depicting a process that can be used toimplement a portion of the Go2 Application program according to anembodiment of the present invention.

[0031]FIG. 18 is a flowchart depicting a process that can be used toimplement a process performed by the primary server upon connection withthe client according to an embodiment of the present invention.

[0032]FIG. 19 is a flowchart and block diagram useful for describing theinteraction and processing between the client, the primary server and anenhanced server according to an embodiment of the present invention.

[0033]FIG. 20 is a flow chart depicting a method that can be used toimplement the automatic location data collection feature according to apreferred embodiment of the present invention.

[0034]FIG. 21 depicts an example of a site plan that can be used toimplement an embodiment of the present invention.

[0035]FIG. 22 is an exemplary embodiment of a database record of theUniversal Geographic Database.

[0036]FIG. 23 is an exemplary geocoding conversion engine that may beused to convert a supplied street address to an ULA for storage in theUniversal Geographic Database.

[0037]FIG. 24 is a flowchart that generally describes an embodiment of ageocoding process.

[0038]FIG. 25 is a block diagram of a Universal Geographic Databasecreation system constructed in accordance with an embodiment of theinvention.

[0039]FIGS. 26A and 26B are a flowchart of an exemplary process forregistering a business proprietary name in the Unified GeographicDatabase.

[0040]FIG. 27 is a block diagram of an embodiment of a Tier 2 levelserver arrangement including a UGD server, a Location Name Serviceserver, and a client.

[0041]FIG. 28 is a block diagram of an embodiment of a Tier 1 levelserver arrangement including a UGD, a geocoding conversion engine, and aclient.

[0042]FIG. 29 is flow chart for an exemplary Go2 query transaction forretrieving information from records in the UGD.

[0043]FIG. 30 is a block diagram of a computer useful for implementingcomponents of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0044] The present invention involves a Unified Geographic Database(“UGD”) and method of creating, maintaining, and using the same throughone or more Location Name Service. In a preferred embodiment of the UGD,each record of the UGD includes a unique, domain-name like hierarchicalgeographical referencing address that represents a real-world locationfor a business or other entity, serves as a discrete identifier for adatabase record in the UGD for accessing the record, and provides auser-friendly naming convention and interface for all types ofelectronic devices. In order to understand the importance of thisdomain-name like hierarchical geographical referencing address in theUGD, it is helpful to understand the basis for the hierarchicalgeographical referencing address, the World Geographic ReferencingSystem (“WGRS”) developed by Go2 Systems, Inc. (“Go2”) of Irvine, Calif.A discussion of the WGRS is in U.S. Pat. No. 5,839,088, U.S. Pat. No.6,047,236, and U.S. patent application Ser. No. 09/257,462, all assignedto Go2, and is generally set forth below in sections I-VI below. SectionI describes an exemplary process for creating the WGRS. Section IIdescribes the WGRS in use. Section III describes details and examples ofWGRS Implementation. Section IV describes several exemplary applicationsof the WGRS. Section V describes some examples of softwareimplementation related to the WGRS. Section VI describes aninternet-based automatic location referencing system using the WGRS. Thefinal section, Section VII, describes the UGD and exemplary methods forcreating, maintaining, and using the same through the LNS.

[0045] I. World Geographic Referencing System

[0046] An embodiment of the WGRS or geographical referencing system willnow be discussed. The WGRS allows a point of interest (“POI”) within anarbitrary geographic area to be uniquely identified with a unique,domain-name like hierarchical geographical referencing address orlocational address, and the locational address to be related to otherknown global referencing systems.

[0047] A. Creation of the World Geographic Referencing System

[0048] The WGRS is created by dividing a geographic area into severaldistricts. The districts may be of the same or differing size and shape,and may contain a particular identifying feature. For example, thegeographic area of the United States may be subdivided into numerousdistricts, which may be strategically located, sized, and named withreference to cities or other geographic or political features in orderto associate the districts with such features. Advantageously, suchdistricts are chosen relative to cities and other well-known landmarksand it is therefore convenient to name each district according to thecity or landmark about which the district is located. In fact, each citymay have a reference point, allowing local locations to be addressedrelative to the local city. Preferably, the districts are square and allof the same size, e.g., 100 km×100 km, with overlapping portions ofdistricts nested with each other. However, in alternative embodiments,sparsely populated areas may have larger districts, and denselypopulated areas may have smaller districts. The districts may also bequasi-rectangular, following latitude and longitude lines. In moredensely populated areas, it is possible that a particular location willbe within the boundaries of two or more districts. In addition,user-defined districts, reference points, and grid sizes are possible.For example, a search and rescue operation may establish a referencepoint and grid size convenient for a particular search area, or a groupof hikers may choose a reference point and grid size appropriate for aparticular outing.

[0049] After the districts have been selected and named, a referencepoint is chosen for each district, and a grid system placed relative tothe reference point. Advantageously, the grid system is referencednorth. Referring to FIG. 1, a first district 1 and a second district 3are defined relative to major cities 4 and 6 respectively. In thisexample, major city 4 in the first district 1 will be named CITYONE andthe major city 6 in the second district 3 will be named CITYTWO. One orboth of these cities 4, 6 could be local cities. For convenience, thefirst district 1 will be named CTY1, referring to the major city withinthat district's borders, and the second district will be named CTY2,referring to the major city within that district's borders. Referencepoint 5 is selected as the reference point for CTY1, and reference point7 is selected as the reference point for CTY2. The reference point willnot necessarily be located proximate to the feature used as the name forthe district. Each reference point 5 and 7 has a known address within aglobal referencing system such as World Geodetic Systems (WGS).Association with a global system offers at least three importantfunctions: first, local addresses may be easily converted to globaladdresses and vice-versa; second, inter-district relationships areestablished; and third, easy integration with known navigational systemsis provided. Thus, an easy to use district-level addressing systemretains the advantages of a global system without attaching complexity.

[0050] As can be seen in FIG. 1, the grid system about each referencepoint 5 and 7 creates cells 9 in each district. Each of these cells 9 isidentified with a cell code, which advantageously is a two characternumber. The grid system is better understood when discussed inconjunction with an exemplary target POI location such as POI location19 within the grid system. For example, the target POI location 19,which is in cell 11, can now be identified by a domain-name likehierarchical geographical referencing address or universal locationaladdress (“ULA”) referring to its district and cell code, e.g., CTY2-11.For example, if CTY2 is Los Angeles, the hierarchical address for thePOI location 19 may read US.CA.LA.11, where “US” indicates that POIlocation 19 is in the United States, “CA” further indicates the POIlocation 19 is in California, “LA” further indicates the POI location 19is in the Los Angeles grid, and “11” further indicates that the POIlocation is in cell code 11 of the Los Angeles grid. Of course, portionsof the address such as “US.CA” may be removed from the address if thisis self-evident or always understood so that the POI location 19 may beunderstood by the address LA.11. Although the address CTY2-11 or LA.11lacks the resolution to identify a particular feature, such as a house,the address may be enough resolution to locate a lake or park. As willbe discussed in more detail below, the POI location 19 can be addressedby further hierarchical sub-cell or sub-grid addressing to identify aparticular feature, e.g., the POI location may be a house that may bespecifically identified by the hierarchical addressU.S.CA.LA.11.17.18.12. Thus, the hierarchical nature of the WGRS and thedomain-name like addressing system based on the same allowsmulti-precision searches to be performed. The issue of increasedresolution is discussed below.

[0051] Also, it is likely that there will be an overlap area 13 that isformed at the intersection of districts. Within this overlap area 13,any POI can be identified by reference to any district within which itis located. Thus, a target location 8 in the overlap area 13 can beidentified by either association with the CTY1 or CTY2 districts, or anyother district within which it is located. In the preferred embodiment,a locational system can provide a locational address relative to anyreference point or district by simply toggling between reference points.Although the grids 1, 3 are shown at an angle relative to one another,the grids 1,3 are preferably aligned with each other and overlappingcells 9 of relative grids such as those shown in overlap area 13 arenested so that they directly overlap or coincide with each other.

[0052] As discussed above, a district name and cell code may not givesufficient resolution to locate specific locations such as a house orbusiness. To increase resolution, a hierarchical grid is applied to eachcell 9 of FIG. 1. For example, cell 11 is shown in FIG. 2 with asub-grid applied, producing sub-cells 15. Each of these sub-cells can beidentified with a sub-grid code. Moreover, the sub-cells can be furthersubdivided to increase resolution. Here, sub-cell 17 is furthersubdivided. As can be seen in the figure, the target location 19 iswithin the sub-sub cell 18. Thus, to more definitively identify thetarget location 19, an ULA is formed from the highest resolutionsub-cell defined and each of its parent cells. The locational address isformed by appending to the district name each sub-cell code inhierarchical progression, moving from lower resolution to moreresolution. In the Los Angeles example here, the target location 19would have a locational address of CTY2-11-17-18 or LA.11.17.18. Basedon the size of the district, if this does not give the necessaryresolution to properly locate the target location 19, then additionallevels of gridding hierarchy can be added. Although, in this example,each cell was randomly named with a unique numerical code, it should beappreciated that a consistent Cartesian coordinate system can also beused, with each cell defined by an (X, Y) coordinate pair. Preferably,each cell is identified by an easting cell designator or X axiscoordinate, paired with a northing cell designator or Y axis coordinate,with the easting cell designator as first number or letter in the pairand the northing cell designator as the second number or letter in thepair. Those skilled in the art will recognize several other alternativeways to define a grid system, some of which are described further below.

[0053] Advantageously, a city or landmark area will be named with aspecific abbreviated name for purposes of navigating to and around thatcity or landmark area. That abbreviated name may also serve as the nameof the defined district located about that city. Preferably, the gridestablished for each city or landmark area is preferably a constant10×10 grid, 100×100 km, or 10,000 sq. km. and overlapping cells fromoverlapping city or landmark areas are nested so that cells directlyoverlap or coincide with each other. In an alternative embodiment,depending on the size of the city and various geographic, political, andother features relating to the city or region, the district for thatparticular city may be pre-defined with a particular grid size, althoughthe system may allow altering the grid size for particular purposes. If,in the preceding example, the defined grid size for CTY2 isapproximately 30 by 30 nautical miles, identifying two hierarchicalgrids produces a resolution of about 500 meters, which is sufficient forlocating structures in open areas or large targets such as lakes orparks. By adding a third and fourth hierarchical grid, a resolution ofabout 5 meters is achieved, and by adding a fifth hierarchical grid, aresolution of about 0.5 meters is achieved. By adjusting the number ofgrids, then, the resolution of the resulting locational address ischanged to meet the requirements of the particular area or user.Advantageously, similar to a domain name for a web address, each levelof the hierarchical address is separated by a decimal point. Thus, anaddress may appear as “DISTRICT.12.34.56.78”. Those skilled in the artwill recognize several alternatives to this approach.

[0054] B. Alpha Codes

[0055] In a preferred embodiment, the above coding technique is extendedto include standard alpha codes representing objects such as suites,floors, rows, columns, altitude, etc. These alpha codes areadvantageously appended to the above code as they logically representthe highest resolution component. Thus, for example, suppose the abovelocational address of CTY2-11-17-18 represents an office building, thenthe address of CTY2-11-17-18-S101 represents suite 101 in the officebuilding. Likewise, the address CTY2-11-17-18-F2 represents the secondfloor of the office building. In another example, the addressCTY-11-17-18-R101-RW12-C22 represents row 12 column 22 in room 101 ofthe office building. This can represent an exact location within aparticular rack in a warehouse, for example. In another example, theaddress CTY2-11-17-18-HS2200 represents a height of 2200 feet above sealevel.

[0056] As can be appreciated by those skilled in the relevant art(s),this technique can be extended as much as required. Typically, astandard set of codes is defined for each specific implementation of thepresent invention. An example of such a set of codes that can be used inan embodiment of the present invention is shown below in Table 1. TABLE1 Example set of alpha codes and their definitions. Alpha CodeDefinition AL AISLE A APARTMENT AD ADDRESS BX BOX B BIN BY BAY C COLUMNCS CASE D DOOR DP DEPTH DY DAY EL ELEVATOR EN ENTRY E ELEVATION ESESCALATOR F FLOOR FD FIELD GR GARAGE G GATE H HEIGHT HE HEIGHT ABOVEELLIPSOID HG HEIGHT ABOVE GEOID HO HEIGHT ORTHOMETRIC HS HEIGHT ABOVESEA LEVEL HT HEIGHT ABOVE TOPOGRAPHICAL SURFACE HU HOUSE LK LOCKER LLEVEL NO NUMBER PO P.O. BOX PH PHONE PN, PIN PIN # R ROOM RW ROW RD ROADST STREET S SUITE SC SECURITY CODE SN SECTION SE SEAT T TIME TR TRAM TNTRAIN TK TRACK U UNIT X INTERSECTION z ZIP CODE

[0057] C. Proprietary Location Address

[0058] The second way a point of interest may be designated in thesubject invention, in addition to its ULA, is with a proprietarylocational address (“PLA”). Referring to FIG. 4, the first step in usinga PLA is to identify the feature and select a name 51. A PLA is a namechosen to identify a physical structure or location. The name can bechosen by the operator of a locational service, as in the case of namingnational monuments, or the name can be chosen by individual or corporateusers of the locational service. Individuals may even want to identifytheir homes using their own names. Thus, a Ms. Mary Smith may name herhouse MARY.SMITH.HOUSE, for example. Thus, when Ms. Smith wants todirect someone using a locational service to her house, she identifiesher location using MARY.SMITH.HOUSE, rather than a street address orother locational referencing system. A corporation, too, may desire toallow customers to locate it using a common name rather than a lesspersonal addressing system. For example, a nationwide enterprise such asMcDonalds® with many locations may choose a PLA that is associated withits tradename or product or otherwise allows users to easily rememberand associate the establishments PLA. Abbreviations are useful as itkeeps user input to a minimum, increasing safety, reliability, andconvenience. Since the nation-wide enterprise may have many locations ina single metropolitan area, each may be identified by appending to theenterprise's PLA a unique identifier to identify specific branch officesor affiliates. Wildcard searching is also provided, allowing severallocations of the known nation-wide enterprise to be found for aparticular geographic area.

[0059] The capture of positional information for a certain name will nowbe described. Referring to FIG. 4, as indicated by identifying numeral55, positional information could be entered manually, by, for example,inputting the ULA or coordinates of the location from a known mappingsystem. Alternatively, as indicated by identifying numeral 57, thepositional information may be read electronically using a system such asthe GPS. Referring again to FIG. 4, the name 51 and positionalinformation 53 are associated. The district in which the location isidentified is determined by comparing the positional information 53 tostored district locational information 54. Once the district isidentified, the name is checked against other reserved names in thedistrict to assure the selected name is unique. If the name is unique,it is placed in a district data file 63. As can be seen from thediscussion above, uniqueness of the name need only be checked at thedistrict level. Consequently, the same name can be present in differentdistricts. The name must be unique at the district level as the districtname usually becomes part of the PLA. For example, the nation-wideenterprise location in district CTY1 could have a full PLA ofCTY1-TRADENAME. If the owner of a name desires to more widely reserve aname, each district will be checked individually.

[0060] Once a PLA is approved for an individual, corporation, or otherentity, the PLA may be placed in promotional material such asadvertisements, coupons, billboards, or other means of communication. Byproviding a PLA that describes a feature, a particular location may bequickly identified and readily found.

[0061] Once cleared for conflicts, the name, positional information, andany other useful information are stored in a central repositorylocation. This storage may be sortable and selectively downloadable byusers of locational systems. For example, the central repository may beaccessible via the Internet. In such a case, a user 75 would make arequest for information 71 concerning future travel, such as the ULAs orPLAs of specific desired waypoints of a trip. The information in thecentral repository 65 is selected and sorted, and the travel data 73 isreceived by the user, creating a travel profile. To ease the dataselection process, the central repository may store preferences for theuser. After receiving the travel profile, the user places the traveldata 73 into a navigational unit 77, augmenting information 79 alreadylocally present in the navigational unit 77. The user 75 may then usethe travel data 73, including PLAs and ULAs, to assist in navigating.

[0062] II. Method of Using World Geographic Referencing System

[0063] The WGRS will now be described in use. Initially, the process fordetermining a WGRS address will be discussed, followed by the processfor converting between WGS and WGRS addresses.

[0064] A. WGRS Address Determination

[0065] Use of an ULA in a navigation system and an exemplary method forWGRS address determination will now be described. Referring to FIG. 3,district file 31 is maintained correlating district names and locationalinformation relating to those districts. Regional information 33, thatmay be manually entered (as indicated by reference numeral 21) by auser, may also be maintained. This regional information 33 is used bythe system to reduce the amount of information a user must enter toidentify a particular location. The regional information may, forexample, be a map code or distinct name identifying the general areacovered by the map. Alternatively, it may be the name of a districthaving a pre-defined grid. After the map code or district name isinputted as regional information, the system now assumes that any futureuser inputs are within the geographical area defined by the regionalinformation, thus reducing the complexity of inputting future addressesreferenced on that map. Also, positional information 35 of a currentlocation may be input manually (reference numeral 23) or electronically(reference numeral 25) for the same purpose. By knowing the presentlocation, the system may assume that any subsequent address input by theuser is within the same geographical area as the present location.Again, the purpose and effect is to reduce the complexity of inputtinglocational addresses.

[0066] The user may also electronically (reference numeral 29), ormanually (reference numeral 27) input a specific address 37 to thesystem. By comparing the regional information 33 and positionalinformation 35 of the current location with the stored districtinformation 31, a general address can be formed. This general addresswill contain the district name plus any cell and sub-cell codes that aremore general than the most general code in the specific address. Theresolution detector 43 attempts to determine how much resolution isrepresented by the specific address 37 input by the user, and inconjunction with the comparison 41 function, creates a general address45 with the correct level of resolution. Again, it is assumed that anysubsequent addresses input by the user are within the same geographicalarea defined by this general address.

[0067] Once the resolution of the specific information 37 is determined,the specific information 37 is passed on to become a specific address47. This specific address 47 is appended to the general address 45formed above to form the final locational address 49. The locationaladdress 49 is then used by the navigational system to assist innavigation. Additionally, an emergency mode may be provided in which apresent location is automatically referenced to any reasonably close PLAor other known location.

[0068] B. WGRS Address and WGS Address Conversion

[0069] A relationship with World Geodetic System 1984 (“WGS-84”),allowing locational addresses to be converted to other global addressingsystems, is also provided. A further description of the district grid isneeded to understand this relationship. Each district has a referencepoint, with the reference point being the approximate center of the cityused in naming the district. A grid is placed in relation to thereference point such that the origin of the grid is aligned with thenearest intersection of latitude and longitude lines corresponding tothe largest grid resolution in the district. Since the reference pointhas a known WGS-84 address, by knowing the origin offset, the districtrotation, and the district scale, every WGRS ULA can be translated intoa WGS-84 address, and from there into nearly all locational referencesystems. Conversely, every WGS-84 address may be translated into one ormore WGRS ULAs. The translation is simplified in the subject inventionas the district grid system is generally aligned to the WGS-84latitude/longitude grid.

[0070] C. Use of the WGRS in a Navigation System

[0071] The aspects of the WGRS may be performed locally such as in amobile navigation system or remotely such as at a remote serve. Withreference to FIG. 5, aspects of the WGRS will described in conjunctionwith a mobile navigation system. An exemplary navigational systemcomprises a GPS receiver 100, an input device 101 such as a keypad orthe like, a processor 102, a storage device 103 such as RAM or ROM, andan output device 106 such as a display. The GPS receiver 100, inputdevice 101, storage device 103, and output device 106 are all coupled tothe processor 102 as shown. An application program 104 executes in theprocessor to perform various tasks. Optionally, a look-up-table(hereinafter “LUT”) 105 is provided in the storage device 103.

[0072] The application program in a conventional navigational apparatustypically interfaces with and directs the aforementioned elements toperform the following tasks:

[0073] 1. Displays the latitude and longitude (hereinafter “lat/lon”) ofthe unit—First, the GPS receiver receives signals from the GPS satelliteconstellation, and calculates the location of the unit (in terms oflat/lon) using these signals. The lat/lon coordinates of the unit arethen displayed on the output device 106.

[0074] 2. Displays velocity and bearing—if the unit is moving, theprocessor determines the location of this unit at selected timeintervals, and based thereon, determines velocity and bearing. Oncedetermined, this information is displayed on the output device 106.

[0075] 3. Allows for the selection of waypoints—In one approach, a userinputs waypoints through input device 101 in terms of lat/loncoordinates. In another approach, common in the aviation community, alook-up-table or the like, identified with numeral 105 in FIG. 5, isprovided, correlating pre-determined waypoints with lat/lon coordinates.A capability for searching through the database and selecting particularwaypoints is also provided in this approach.

[0076] 4. Displays distance and bearing from selected waypoints—once thewaypoints have been determined, the distance (assuming straight line)and bearing from these waypoints is determined and displayed.

[0077] Additional components of the system which are added by thesubject invention include context buffer 108; front-end interface(hereinafter “FEI”) 107; PLA database 110; and a database(s) 109 of griddefinitions.

[0078] A critical function of the front-end-interface is to convert ULAsand PLAs into lat/lon coordinates. Consequently, a user can inputwaypoints in terms of ULAs or PLAs, and the FEI will convert the same tolat/lon coordinates for use by the unit in determining a directionaland/or distance indicator (such as distance and bearing) from thewaypoints. Additionally, positional information defined in terms oflat/lon coordinates can be displayed in terms of one or more ULAs of thesubject invention. The FEI also includes various searching capabilitiesto allow a user to search through the PLA database 110 for particularwaypoints or waypoints with particular characteristics.

[0079] The function of the context buffer 108 is to define the currentdistrict and grid in which grid addresses are assumed to be defined.

[0080] The grid definition file(s) 109 specifies all the grids whichhave been defined to date. For each grid, all the parameters necessaryto define the gird are stored. Such information includes the lat/loncoordinates of the reference point of the grid, the dimensions of thegrid, and the rotation and scaling of the grid cells. Thus, all theinformation needed to convert between a grid address within the grid andlat/lon coordinates is provided.

[0081] The PLA file 110 is a file which for each district correlateseach PLA which is unique to and has been reserved for use in thedistrict with its corresponding grid address.

[0082] The navigational system described above may be mounted in avehicle or contained in a portable device, for example. Additionally,the navigational system may stand alone or may be integrated intoexisting devices, such as portable phones. Further, the subjectinvention may be incorporated into a general computational device suchas a microprocessor. Since the physical manifestation of thenavigational system is so flexible, there are numerous foreseeableapplications.

[0083] III. Details and Examples of WGRS Implementation

[0084] The examples set forth below describe various details of variousimplementations of the WGRS. Examples 1, 1A, 2, and 3 demonstratespecific implementations of one embodiment of the invention: Example 1demonstrates the use of Hierarchical Identifiers for districts which arecorrelated with Country, State/Province, and City districts along withPLA's and a purely numeric ULA grid referencing system based upon adistrict grid size of approximately 100 kilometers from north to southor approximately 100 miles (185 kilometers) north to south. Example 1Ademonstrates an alternative means that can be used to implement the citygrid based on the Transverse Mercator projection system. Example 2demonstrates the use of the Hierarchical Identifiers described inExample 1 along with an alternating alpha-numeric ULA grid referencingsystem. Example 3 demonstrates the use of a smaller City Grid and theresulting higher precision at various grid levels.

A. EXAMPLE 1

[0085] Hierarchical Identifiers for Country, State/Province, City

[0086] The example assumes the existence of higher levels ofhierarchical codes for identifying countries, states/provinces, andcities. The top level codes can be used, implied by context, orspecifically ignored by the use of dots (periods) to make it clear howmany codes have been omitted. A code of ‘US.CA.LA’ might be representedas ‘LA’, ‘..LA’, or by ‘CA.LA’, depending on the geographic context orthe need for clarity.

[0087] In all cases, upper level codes are dropped when the geographiccontext is clear, to prefix with dots (periods) when necessary to insureclarity, and to append lower levels to add precision.

[0088] Country Codes

[0089] Top level: two alpha character mnemonic (possibly based onInternet domain codes).

[0090] Examples:

[0091] United States=US

[0092] Australia=AU

[0093] Canada=CA

[0094] State/Province Codes

[0095] Second level: two character mnemonics (advantageously based on USpostal codes within the US).

[0096] Examples:

[0097] California=CA

[0098] New York=NY

[0099] City Codes

[0100] Third level: two or three alpha character mnemonics from cityname unique within each state.

[0101] Examples:

[0102] Carbondale=CAR

[0103] Hartford=HAR

[0104] Los Angeles=LA

[0105] New York City=NYC

[0106] Proprietary Codes

[0107] Fourth level; one or more alpha or numeric characters which areunique within a specific grid or map with a unique map code

[0108] Examples:

[0109] MACD, DISNEY, EXXON, etc.

[0110] An example of a use of a PLA might be US.GA.ALB.MACD to refer toa MacDonalds in Albany, Georgia; US.GA.ALB.MACD* to refer to theclosest(s) one in Albany, Georgia; or MACD* to refer to the closest(s)ones in any city.

[0111] The code ..ALB.MACD* could refer to either the nearest MacDonaldsin Albany Georgia or Albany New York and context. .NY.ALB.MACD* wouldresolve the context.

[0112] City Grid

[0113] This optional code is at a fourth or fifth level; identified bythe first use of a pair of numeric characters in the city grid code. Thecity grid system requires an approximate city centroid described in alocational reference system such as geodetic latitude and longitude andthe meaning of each pair of grid designators. The city grid origin isdefined at the south-west coordinate system intersection valuecorresponding to exact values of the largest grid resolution precisionthat is defined in the city grid, placing the district centroid withinthe center grid cell of the system.

[0114] In the nominal city grid system, the grid cells are orthogonal tothe defining coordinate system; however, rotations and scale parameterscan be used to re-define the relationship between the city grid and thereference frame. False easting and false northing offsets (translations)are normally used to avoid negative numbering or to allow convenientordering of alphanumeric designators.

[0115] Conversion from the defining reference frame (e.g., lat/lon) tocity grid designators (i.e., ULAs) is accomplished by computingconversion constants based on the initial reference frame and thespecific city grid definitions. When geographic context has already beenestablished, grid designators are computed with respect to the currentlyselected district. When no district has been selected as the preferredone, the nearest district centroid is used as the basis for the griddesignators. Conversion from city grid to coordinates in the definingsystem is accomplished by applying translation (and when applicablerotation and scale) parameters to the succession of grid designatorsuntil the precision implied by the number of grid cell designator pairsis reached.

[0116] The city grid is nominally based on a locational reference systemthat can be tied to other reference systems. In the nominal system, theunderlying locational reference system datum is the World GeodeticSystem 1984 (WGS-84). Geodetic coordinates with respect to this datumcan be converted to coordinates in a large number of other referencesystems, allowing the city grid designators to be used with respect toother systems and other geodetic datums allowing conversion to UniversalTransverse Mercator (UTM) systems, State Plane Systems, National GridSystems, other horizontal coordinate system, or map projection.

[0117] The city grid origin is defined at the ten minute of latitude andten minute of longitude intersection nearest the city centroid. Thisplaces the origin within five minutes of latitude and longitude of thecity centroid. The radial distance of the city grid origin is thenalways within about 10 km of the nominal city center.

[0118] Each grid is then defined based on this origin by placing a gridcentered at the origin with a false easting and northing=halfway betweenminimum and maximum numeric characters. Grid cells are identified by aneasting cell designator paired with a northing cell designator withsuccessive pairs of designators defining grid cells of increasingprecision.

[0119] Highest level; least precision two numeric characteristics, Eastis always first, North is always second, minimum is always 0 and maximumis always 9.

[0120] The false easting puts the division between 4 and 5 at the gridorigin north and east. Each highest level grid consists of a ten by tenregion (100 grid rectangles).

[0121] Next lower level; higher precision, divides each numeric gridinto a ten by ten grid (100 grid rectangles) area. East is always first,north is always second. Minimum is always 0 and maximum is always 9.

[0122] The false easting again puts the grid rectangle center at thedivision between 4 and 5.

[0123] Next lower levels repeat the numeric code above dividing eachhigher grid rectangle into a ten by ten rectangle area.

[0124] If each city grid origin is at an integer intersection of an eventen minutes of latitude and longitude, the first level numeric gridrectangles each cover an area of approximately 100 square kilometerswith grid cells whose north-south extent is about 10 kilometers. Thusthe entire set of first level grid cells covers a distance of about 100kilometers from north to south and a shorter distance from west to east,depending on latitude. Alternatively, if it is preferred to establishthe city grid system in miles, the first level numeric grid rectangleseach cover an area of approximately 100 square nautical miles, or about343 square kilometers with grid cells whose north-south extent is about18.5 kilometers. Thus the entire set of first level grid cells covers adistance of about 185 kilometers from north to south and a shorterdistance from west to east, depending on latitude.

[0125] Each second level city grid cell is {fraction (1/10)}^(th) of thenext higher level grid cell, or 1 minute of latitude and longitude,about 1 km north to south, or, in a miles city grid system, 1850 metersnorth to south.

[0126] Each third level city grid cell is then {fraction (1/10)}^(th) ofthe second level grid, or 6 seconds of latitude and longitude, about 100meters north to south, or, in a miles city grid system, 185 meters northto south.

[0127] Each fourth level city grid cell is then {fraction (1/10)}^(th)of the third level grid, about 10 meters north to south, or, in a milescity grid system, 18.5 meters north to south, around 340 square meters.

[0128] Since this fourth level grid corresponds to a resolution somefive times more precise than un-aided GPS accuracy (with SelectiveAvailability), a fifth level grid may not be required. Following thesame {fraction (1/10)}^(th) rule as the higher level grids, a fifth gridcell would measure 1 meter on a side, or, in a miles city grid system,1.85 meters on a side, well within the accuracy of differentially-aidedGPS.

[0129] Cities close to each other can each employ their own city grideven when they overlap. When questions of which city grid occur the citycode (or all the higher level codes) can be attached to removeambiguity.

[0130] An example of a use of an ULA might be US.GA.ALB.13 to refer toan area, in a miles city grid system, about 20 kilometers wide southwestof the center of Albany Georgia. Then ..ALB.13.78 would refer to an areaabout 2 kilometers wide near the northeast comer of the previousexample. So would .13.78 if the geographic context was established asAlbany Georgia.

[0131] The code .US.GA.ALB.13.78.27.14, in a miles city grid system,would refer to the smallest unit of about 9 meters within an explicitlydefined place. ..78.27.14 would refer to the same place in context.

B. EXAMPLE 1A

[0132] In addition to the example above which demonstrates one means forimplementing the city grid, this example describes an alternative meansfor implementing the city grid based on the Transverse Mercatorprojection system.

[0133] In a preferred implementation a conventional mapprojection/coordinate system grid is selected. While Lambert ConformalConic, Stereographic, or local tangent plane system might well be used,in this example, the Transverse Mercator (TM) projection is selected.The TM projection is preferred over other projections suitable for usein local mapping systems because it is most likely an availableprojection in many GIS and GPS platforms.

[0134] To make city centroid selection less contentious an issue, onepreferably uses lists of centroids from the Digital Chart of The World(VMapO) or other sources and moves them to arbitrary points that aredefined in controlled lists. In order to remove the slight differencesin city centroids from different lists, and to standardize the method offixing the preferred list, the city grids are centered at the nearest0.05 degrees of latitude and longitude, assuring that the “centroid” isalways within the 55 first level cell, and always within about 5.5 km ofthe center of the grid. This use of decimal degrees rather than valuesin minutes makes internal computations easier and less subject tocomplex issues such as repeating fractional values (i.e. 50minutes=0.8333333333 . . . degrees).

[0135] In this example, the city grids are Transverse Mercator gridswith the following characteristics:

[0136] Origin latitude and longitude “snapped” to the 0.05 degreeincrement south-west of the city centroid.

[0137] Scale at the origin=1.0

[0138] False easting 50,000 meters

[0139] False northing 50,000 meters.

[0140] Normal TM projection formulas as documented in Snyder (1987) andused in almost everyone's TM routines.

[0141] The grid cells for all level grids start at 00 in the south-westcorner, increasing to 99 at the north-east comer following this simplepattern: 09 19 29 39 49 59 69 79 89 99 08 18 28 38 48 58 68 78 88 98 0717 27 37 47 57 67 77 87 97 06 16 26 36 46 56 66 76 86 96 05 15 25 35 4555 65 75 85 95 04 14 24 34 44 54 64 74 84 94 03 13 23 33 43 53 63 73 8393 02 12 22 32 42 52 62 72 82 92 01 11 21 31 41 51 61 71 81 91 00 10 2030 40 50 60 70 80 90

[0142] Each Level 1 grid cell covers a 10 km by 10 km square region onthe ground

[0143] Each Level 2 grid cell covers a 1 km by 1 km square

[0144] Each Level 3 grid cell covers a 100 meter by 100 meter square

[0145] Each Level 4 grid cell covers a 10 meter by 10 meter square

[0146] The grid cells are exactly these distances north-south andeast-west of the center of the grid.

[0147] The scale factor of 1.0 at the grid origin means that largestdistance error is less than 4 meters over the extent of the grid.

[0148] As an example using the US.DC.WAS grid, the ellipsoidal distancefrom southwest comer to northeast corner is 141419.494 meters. Computedusing the TM grid as though it was orthogonal one would compute a rangeusing the Pythagorean theorem of 141421.356 meters, a difference of1.862 meters.

[0149] These grids then can be used for very accurate distance estimatesas well as making their use with any existing map quite simple. Inaddition, it should be noted that the grid cell designators can beeasily computed from the output of any existing TM routine (such asthose found in GPS receivers for user grids) using the TM parameters.For instance the position of the Smithsonian Institution in TM eastingsand northings is:

[0150] 52072.6 East and 48736.0 North.

[0151] The grid designators are simply extracted from the powers of tenone digit at a time, east followed by north as:

[0152] 54.28.07.73 for ten meters, or 54.28.07.73.36 for a one meterlevel grid.

[0153] To put a grid designator value into a TM conversion, one makeseasting and northing values from the grid designator in the same way.

[0154] For instance a random designator of:

[0155] 39.12.46.15.53, results in: 31415 meters Easting and 92653 metersNorthing

[0156] or

[0157] 39.12.46, results in: 31400 meters Easting and 92600 metersNorthing.

C. EXAMPLE 2

[0158] In addition to the example above which demonstrates the logic andstructure of the XYZ.12.34.56.78 format, this example describes the useof a grid format and ULA utilizing the XYZ.12.aa.34.aa format. TheCountry, State/Province, City and Proprietary Codes remain as describedin the previous example, but the optional City Grid is structureddifferently. The grid code is still initially identified by a pair ofnumeric characters, and the city grid origin is defined at the tenminute of latitude and ten minute of longitude intersection nearest thecity centroid as in the previous example. The definition of each gridand the false easting and northing, as well as the structure of thefirst grid level, is also as described in the preceding example.

[0159] The next lower level of the grid divides each numeric grid into atwenty by twenty grid (400 grid rectangles) area. East is always first,north is always second. The minimum is A from a character set consistingof ABCDEFGHJKLMNPQRSTUV, and the maximum is V. The false easting putsthe grid rectangle center at the division between K and L.

[0160] The next lower level repeats the numeric code as described in thepreceding example dividing each higher grid rectangle into a ten by tenrectangle area, and the next lower level repeats the alpha codedescribed above in this example dividing each higher grid rectangle intoa twenty by twenty rectangle area.

[0161] If the city grid is the same size as the preceding example, eachsecond level city grid square (represented by the code XYZ.12.aa) is{fraction (1/20)}th of the first numeric grid square, 30 seconds oflatitude and longitude, or about 920 meters north to south. The thirdlevel city grid square (represented by the code XYZ.12.aa.23) wouldresult in a grid rectangle size of approximately 3 seconds of latitudeand longitude, or about 92 meters north to south. The fourth level citygrid square (represented by the code XYZ.12.aa.23.aa) would be {fraction(1/20)}th of the previous city grid square size, resulting in a gridrectangle size of approximately 0.15 seconds of latitude and longitude,or about 5 meters north to south.

[0162] It should be appreciated that it is possible to defineembodiments in which these higher level portions are defined in terms ofeither numeric or alpha characters, or alternatively, in terms of mixedalpha and numeric characters.

D. EXAMPLE 3

[0163] This example demonstrates the different precision achievable byvarying the size of the city grid of a particular district. This exampleuses a sample city grid designator “US.TX.AUS.45.45.77.45,” with adistrict centroid of 30 degrees, 17 minutes north latitude and 97degrees, 45 minutes of west longitude for an Austin, Tex., city griddistrict with a district designator, “US. TX. AUS.” For a city grideasting and northing resolution of 1 minute of latitude and longitudefor the largest resolution grid designator pair, the grid origin wouldbe placed at 30 degrees, 17 minutes north latitude and 97 degrees, 45minutes west longitude.

[0164] For numeric city grid designators with no rotation or scale, andwith a false easting and northing of five grid cells, the designator“US.TX.AUS.45.45.77.45” would correspond to a geodetic position of 30degrees, 15 minute, 45.0 seconds north latitude, and 97 degrees, 45minutes, 15.0 seconds west longitude. The precision of the smallest gridcell would be one thousandth of a minute of latitude and longitudecorresponding to approximately 1.6 meters of easting and 1.9 meters ofnorthing. By reducing the number of designator pairs the precision ofthe implied geodetic position is also reduced. In this example, adesignator of “.TX.AUS.45.45”, would refer to an area one tenth of oneminute of latitude by one minute of longitude in area or approximately185 meters north to south; “.AUS.45.45.77” would refer to an areaone-hundredth of one minute by one-hundredth of one minute, orapproximately 18.5 meters north to south.

[0165] IV. Exemplary Applications of WGRS

[0166] Set forth below are several exemplary applications of the WGRS.Examples 4 through 7 reflect situations in which the invention may beused and provide marked improvements in function and utility overtraditional lat/lon based systems. Example 8 demonstrates certainaspects of the invention related to a particular geographic area and twomaps of partially overlapping areas.

A. EXAMPLE 4

[0167] The subject invention may be used for general vehicularnavigation, to drive from Los Angeles to the visitor's center at theGrand Canyon. The driver must first determine the address for the targetlocation, and then input the address into the navigational system. Thereare several alternatives for locating the PLA or ULA. For example, thedriver may read travel brochures that contain the ULA/PLA addresses; thedriver may also review a map which contains ULA/PLA annotations; or thedriver could just call the Visitor's Center and ask them for their PLAor ULA. Alternatively, the driver, using the input device, could searchthe PLA database to find if the Grand Canyon visitor's center has a PLA.Once the address is determined, the driver enters the PLA or ULA addressinto a navigational system, and the navigational system will direct thedriver to the proper destination.

B. EXAMPLE 5

[0168] Second, the subject invention may be used to direct local trafficto a particular point of interest. For example, if the driver above istraveling along a highway and becomes hungry and desires to eat at aparticular fast-food chain, the driver could interrogate the system datato find any nearby chain restaurants. The driver simply queries thenavigational system for occurrences of the fast-food chain's PLA, and,since the navigational system is aware of its current location, thechain's restaurants may be listed by proximity. The driver simplyselects one of the restaurants, and the navigational system directs thedriver to that location. Additionally, a local restaurant may advertisean ULA or PLA for its location, so a driver, seeing a billboard oradvertisement containing an ULA or PLA address, could input that addressand be directed to the restaurant location. Because of the unique styleof the addresses and features of the subject invention, these addressesare particularly easy to input with a minimum chance of error,decreasing the risk of accidents and increasing the likelihood of goingto the desired location.

C. EXAMPLE 6

[0169] Third, the subject invention is particularly well suited forcustomization by individual or team users, facilitating intra-groupcommunication and navigation. For example, if a group of hikers desiresto split up and explore a particular area, they each could set theirportable navigation devices to reference a custom grid with anappropriate grid size and location for the explorable area that allowssufficient resolution with a minimum number of digits or characters.Now, as the hikers communicate with each other or record interestinglocational information, the data may be easily and accurately used andreferenced to a meaningful location. This ability to set a user-definedreference point and grid size would also be useful for rescue teamsperforming search and rescue operations by allowing the search andrescue team to instantly establish a grid size and location for anysearch.

D. EXAMPLE 7

[0170] Fourth, the subject invention has emergency utility. For example,if a hiker above needs emergency assistance, the navigational system canprovide a locational ULA that is easy to read and communicate by voiceor numeric only key pad, which reduces both the ambiguity, risk and timeinvolved in describing an emergency location. Alternatively, this ULAmay be automatically communicated to emergency personnel if thenavigational system integrates with a portable phone, two way pager, orother portable communication device.

E. EXAMPLE 8

[0171] An example illustrating the use of PLAs and ULAs in a specificgeographical context, Yosemite National Park, will now be described.FIG. 6 illustrates a paper map with an assigned name of CA.YSB(indicated by identifying numeral 111). Within the boundariesrepresented on this map, the following PLAs have been reserved:Corresponding identifying PLA Description of Location numeral HFDM HalfDome 115 1 Ahwahnee Hotel 112 GCRP Glacier Point 114 YSMF Lower YosemiteFall 113

[0172]FIG. 7 illustrates a district with an assigned name of CA.YSM(indicated by identifying numeral 120). Within this district, thefollowing PLAs have been reserved: Corresponding identifying PLADescription of Location numeral HCHY Hetch Hetchy 121 11 White Wolf 122NENT Big Oak Flat Entrance 123 GCRP Glacier Point 126 WENT Arch RockEntrance 124 BDGP Badger Pass 125 1 Wawona Information Center 128 SENTSouth Entrance 127

[0173] The following points should be noted from this example:

[0174] First, the name CA.YSB is for the specific map included in FIG.6, and not for a district in which all of the area contained on the mapis included. This feature allows assignment of specific PLA's forspecific maps without regard to the district, thereby providing clarityin situations where the area covered by the map overlaps one or moredistricts.

[0175] Second, the name CA.YSM is the name of the district in which thearea included in the map in FIG. 7 is located, thereby allowing areasincluded within this map to be referenced by either PLAs (e.g.CA.YSM.HCHY) or ULAs (e.g. CA.YSM.32.84.23.43) without the need tore-identify the name of the district or map.

[0176] Third, the areas covered by the CA.YSM district and the CA.YSBmap overlap, allowing PLA references to either the YSM district or theYSB map. (Note also that the system might also define YSB as a districtwhich could be utilized in determining ULA's with reference to the YSBdistrict, in which case the YSB and YSM districts would also partiallyoverlap.)

[0177] Fourth, the PLA's for particular locations may either beidentical except for the district name (e.g. GCRP in FIG. 6 and GCRP inFIG. 7 refer to the same location) or identical PLA's may apply todifferent locations in different districts or on different maps (e.g.“1” in FIG. 6 and “1” in FIG. 7 refer to different locations on each ofthe respective maps). This is consistent with the principle that a PLAneed only be unique within the district in which it is defined.

[0178] All of the features described in this example are designed toallow an initial manual or electronic input (either a district code,cell code, or specific map code) which allows users to use PLA's orULA's identified on a specific map with a minimum number of keystrokes,thereby minimizing data entry, confusion, and ambiguity.

[0179] V. Examples of Software Implementation

[0180] Examples 9, 10, and 11 demonstrate certain characteristics offiles, pseudo-codes, and program screens of particular embodiments ofthe invention. (Note that the data contained in the files is providedfor illustrative purposes only).

A. EXAMPLE 9

[0181] In this example, formats of specific files that are used in oneimplementation of the subject invention are described. Four files aredescribed: GO2CITY.DAT, STATES.DAT, PROPGO2.DAT, and COUNTRYS.DAT.

[0182] The GO2CITY2.DAT file, illustrated in FIGS. 8a-8 b, defines thereference points for a plurality of pre-defined districts centeredaround specific cities. For each reference point, there is provided thename of the district, the name of the reference point, and the globalcoordinates of the reference point. Thus, the first entry of this file“AK, ANC, Anchorage, 149W54, 61N13,” indicates that there is a districtin the state of Alaska centered around Anchorage, with the referencepoint thereof having the following global coordinates: 149W54,61N13.

[0183] The STATES.DAT file, illustrated in FIG. 9, simply defines themnemonics used in GO2CITY2.DAT to define states.

[0184] The PROPGO2.DAT file, illustrated in FIGS. 10a-10 c, defines theproprietary names which have been reserved for each district. This filecorrelates each such proprietary name with the global coordinatesassociated with that name. Thus, the first entry of this file,“US.CA.NWB.MAC2, 117W52.360, 33N39.549” indicates that, in a districtcentered around Newport Beach, Calif., there is a MacDonalds having thefollowing global lat/lon coordinates address: 117W52.360, 33N39.549.

[0185] The COUNTRYS.DAT file, illustrated in FIG. 11, simply defines thecountry mnemonics used in PROPGO2.DAT.

B. EXAMPLE 10

[0186] This example illustrates screen formats as displayed on an outputdevice in an implementation of the subject invention. FIG. 12a is ascreen illustrating the input of an ULA or grid address into anavigational system, with the system determining and outputtingcorresponding latitude and longitude coordinates. FIG. 12b illustratesthe input of a PLA, with the system determining and outputtingcorresponding latitude and longitude coordinates. FIG. 12c illustratesthe capability of the system to interpret the context, i.e. districtaddress, of previous addresses, and to assume that the same distinctaddresses applies to subsequent specific addresses until notifiedotherwise. In this specific example, the proprietary name MAC2 wasinput, with the system assuming that the district name associated withthe previous example relating to MAC1, i.e., the CA.NWB. district name,applied to this example as well. Thus, in FIG. 12c, only the identifier“MAC2” need be input to the system, it being assumed that the districtidentifier “CA.NWB” applies to this request as well.

C. EXAMPLE 11

[0187] This document is a functional description of a computer program,Go2Grid, which embodies one or more aspects of the subject invention.The program is written in the “C++” programming language and its purposeis to demonstrate the feasibility of conversion between city grid andproprietary codes and geodetic coordinates.

[0188] Program flow is described using a series of pseudo-codestatements. The functions required to perform these tasks are described.The data variable types and structures are defined. The parametersrequired for implementation of two possible city grid designators aredefined.

Program Flow

[0189] Set all defined parameters to their default values

[0190] Northern latitudes are positive

[0191] Eastern longitudes are negative

[0192] The assumed geodetic datum is World Geodetic System 1984 (WGS-84)

[0193] The last geodetic position is used to initialize the City Griddesignator.

[0194] The user screen is initialized

[0195] Monitor keystrokes or navigation receiver input

[0196] For any City Grid designator change

[0197] Parse user input

[0198] If change in City Code

[0199] Compute city position from designator

[0200] Fill City Code

[0201] Fill Country and State Codes

[0202] If change in State Code

[0203] Fill Country and State Codes

[0204] If change in Country Code

[0205] Fill Country Code

[0206] If change in entire City Grid Designator

[0207] If a Universal Go2 Code

[0208] Fill Country, State, City and Grid Codes

[0209] If a Proprietary Go2 Code

[0210] Fill Proprietary Code

[0211] Compute geodetic coordinates for this Go2 Designator

[0212] For any change in geodetic coordinates

[0213] Parse user input

[0214] If user has requested a Universal Code

[0215] If current geographic context is changed

[0216] Get Go2 Codes from latitude and longitude

[0217] Find closest city

[0218] Set new City Grid center

[0219] Fill Country, State, City codes

[0220] Compute City Grid Codes for each level of precision

[0221] Reset User Screen display

[0222] Continue

Functions

[0223] The following functions are used by the Go2Grid sample program,an embodiment of the city grid concept: getdeg( ) extracts decimaldegrees from character strings grange( ) computes geodetic range betweentwo positions dmsdeg( ) extracts degrees, minutes, seconds from decimaldegrees degdms( ) forms decimal degrees from degrees, minutes, secondsgetcenter( ) computes geodetic coordinates of City Grid center from citycentroid getgrid( ) computes City Grid codes for level of precisiongetkeys( ) parses user keyboard input parsego2( ) parses Go2 City Griddesignator addlatlon( ) concatenates next level of precision ontogeodetic coordinates getnextcity( ) finds next city in currentstate/province list getprevcity( ) find previous city in current state/province list getcost( ) fills Go2 City Grid designator with country andstate/province codes putscreen( ) fills display with current city Griddesignator and geodetic coordinates getnextstate( ) finds nextstate/province in current country list getprevstate( ) find previousstate/province in current country list

Types and Structures

[0224] The Go2Grid embodiment sample program defines the followingvariable structures in addition to the usual character, integer, float,and double types:

[0225] typedef struct ccstruct {

[0226] char city_code[4];

[0227] char city[60];

[0228] char state_code[3];

[0229] char state[60];

[0230] char country_code[3];

[0231] char country[60];

[0232] char longitude[32];

[0233] char latitude[32];

[0234] double lat;

[0235] double ion;

[0236] double centerlat;

[0237] double centerlon; };

[0238] typedef struct latlonstruct {

[0239] int latdeg;

[0240] int latmin;

[0241] int latsec;

[0242] int londeg;

[0243] int lonmin;

[0244] int lonsec; };

Program Definitions

[0245] The following definitions are used within the Go2 Grid sampleprogram: /* grid types */ /* a gridtype = = 1 is numeric with 10minutes, 1.0, 0.1, and 0.001 grids */ /* a gridtype = = 2 isalphanumeric with 10, 0.5, 0.05 and 0.0025 grids */ #define GRIDTYPE 1#define TITLE “Go2 and Geographic Coordinate Converter” #define VERSION“(4/3/96)” /* lines */ #define TITLELINE 1 #define GO2CONTEXTLINE 5#define GEOCONTEXTLINE 10 #define HELPLINE 15 #define MESSAGELINE 18#define COUNTRYLINE 20 #define STATELINE 21 #define CITYLINE 22 #defineGO2LINE 23 #define LATLINE 24 #define LONLINE 25 #define INCOL 23#define OUTCOL 5 #if GRID TYPE= =1 /* GRID GRAIN */ #define GRIDKIND“Numeric City Grid” #define GRIDDEF “Grid Precision: Level 1=1.0′; Level2=1.0′; Level 3=0.1′; Level 4=0.01′” #define GRIDCHARS “DesignatorsLevels 1, 2, 3 and 4: [01232456789]” #define LEVEL 1_EGRAIN 10.0 #defineLEVEL 1_NGRAIN 10.0 #define LEVEL 1_ECHARS “0123456789” #define LEVEL1_NCHARS “0123456789” #define LEVEL 1_EGRIDS 10 #define LEVEL 1_NGRIDS10 #define LEVEL 2_EGRAIN 1.0 #define LEVEL 2_NGRAIN 1.0 #define LEVEL2_ECHARS “0123456789” #define LEVEL 2_NCHARS “0123456789” #define LEVEL2_EGRIDS 10 #define LEVEL 2_NGRIDS 10 #define LEVEL 3_EGRAIN 1.0 #defineLEVEL 3_NGRAIN 0.10 #define LEVEL 3_ECHARS “0123456789” #define LEVEL3_NCHARS “0123456789” #define LEVEL 3_EGRIDS 10 #define LEVEL 3_NGRIDS10 #define LEVEL 4_EGRAIN 0.010 #define LEVEL 4_NGRAIN 0.010 #defineLEVEL 4_ECHARS “0123456789” #define LEVEL 4_NCHARS “0123456789” #defineLEVEL 4_EGRIDS 10 #define LEVEL 4_NGRIDS 10 #else if GRIDTYPE= =2#define GRIDKIND “Alphanumeric City Grid” #define GRIDDEF “GridPrecision: Level 1=10′; Level 2=0.5′; Level 3=0.05′; Level 4=0.0025′”#define GRIDCHARS “Designators Levels 1&3:[01232456789]; Levels2&4:[ABCDEFGHJKLMNPRSTUVW]” /* GRID GRAIN */ #define LEVEL 1_EGRAIN 10.0#define LEVEL 1_NGRAIN 10.0 #define LEVEL 1_ECHARS “0123456789” #defineLEVEL 1_NCHARS “0123456789” #define LEVEL 1_EGRIDS 10 #define LEVEL1_NGRIDS 10 #define LEVEL 2_EGRAIN 0.5 #define LEVEL 2_NGRAIN 0.5#define LEVEL 2_ECHARS “ABCDEFGHJKLMNPRSTUVW” #define LEVEL 2_NCHARS“ABCDEFGHJKLMNPRSTUVW” #define LEVEL 2_EGRIDS 20 #define LEVEL 2_NGRIDS20 #define LEVEL 3_EGRAIN 0.05 #define LEVEL 3_NGRAIN 0.05 #define LEVEL3_ECHARS “0123456789” #define LEVEL 3_NCHARS “0123456789” #define LEVEL3_EGRIDS 10 #define LEVEL 3_NGRIDS 10 #define LEVEL 4_EGRAIN 0.0025#define LEVEL 4_NGRAIN 0.0025 #define LEVEL 4_ECHARS“ABCDEFGHJKLMNPRSTUVW” #define LEVEL 4_NCHARS “ABCDEFGHJKLMNPRSTUVW”#define LEVEL 4_EGRIDS 20 #define LEVEL 4_NGRIDS 20 #endif

[0246] VI. Internet-Based Automatic Location Referencing System

[0247] FIGS. 13-22 are used to describe a preferred embodiment of anautomatic location referencing system using the WGRS described above. Itshould be noted that although this aspect of the present invention couldbe implemented with other types of geographical referencing systems, itis preferably implemented with the WGRS to take advantage of thefeatures described herein.

[0248]FIG. 13 depicts an operational environment of the automaticlocation aspect of the present invention according to a preferredembodiment. A portable-computing device 1302 is installed in a mobileunit such as an automobile 104. Alternatively, the portable-computingdevice 1302 may be carried on the person of individual users. In yetanother embodiment, the present invention can be implemented using anon-portable computing device such as a general-purpose desktop computeror the like.

[0249] However, for the purposes of this example, the device 1302 isreferred to as the portable-computing device. In one embodiment, theportable-computing device 1302 receives data from Global PositioningSystem (GPS) satellites 1310 for location identifying purposes. This isone example of a means for automatic location identification, as shownby block 1301 labeled “ALI Example 1.” A second example of a means forautomatic location identification is shown as block 1303 labeled “ALIExample II.” ALI Example II 1303 is intended to represent a means forautomatically identifying the location of a device, such as device 1302,via a cellular transmission. Example II 1303 typically usestriangulation techniques in conjunction with at least two cellular basestations, or distance measuring techniques from three cellular basestations, such as the base station 1306.

[0250] Additional means for ALI can also be used in alternateembodiments of the present invention. For example, the automaticidentification signals commonly used in land-line telephonic devices(“ANI” and the like), can be used in conjunction with a database lookuptable to identify a callers fixed location.

[0251] In any case, any well-known means for automatically identifying acaller's geographical location can be used in various embodiments of thepresent invention. In fact, future methods, not yet known, but used foridentifying the location of a mobile unit, such as the mobile unit 1302,are within the scope of the present invention. Accordingly, the use ofthe examples of a cellular network and a GPS system should not beconstrued to limit the scope and breadth of the present invention.

[0252] The portable-computing device 1302 has the capability forwireless communications. In this example, one use of the wirelesscommunication feature is to connect the portable-computing device 1302via a wireless network gateway to a computer network such as theInternet 1318. The wireless communication feature of the presentinvention is also used for providing standard telephony functions. Inaddition, as stated above, the wireless communication feature of thepresent invention can also be used to implement ALI functionality inaccordance with the principals described herein.

[0253] In one example, cellular technology is used to implement thewireless communication feature of the present invention. In FIG. 13, thebase station 1306 and the mobile switching office 1308 represents aportion of a typical cellular network. The base station 1306 sends andreceives radio signals to and from the portable-computing device 1302.The mobile switching office 1308 is coupled to the base station 1306 viastandard telecommunication transmission lines. Likewise, the mobileswitching office 1308 is coupled to the public switched telephonenetwork 1312 via standard telecommunication transmission lines. Thepublic switched network 1312 is coupled to the Internet 1318 via apoint-of-presence, which is typically implemented using high bandwidthT3 telecommunication channels or the like.

[0254] A primary server 1314 is coupled to the Internet 1318. Theprimary server 1314 is used to interface with the portable-computingdevice 1302 as described below. The primary server 1314 is coupled witha database or persistent storage device 1316. A plurality of enhancedservers 1315 are connected to the Internet 1318. The enhanced servers1315 provide location specific data to the portable-computing device1302. The primary server 1314 selects a particular enhanced server 1315to be connected to the portable-computing device 1302 in accordance witha database query as described below.

[0255] Note that the present invention is described in terms of aprimary server 1314 and one or more enhanced servers 1315. However, thisdoes not mean that separate physical servers must be used to implementthese functions. Indeed, a single server or multiple servers can be usedto implement the functions of the primary server 1314 and the enhancedservers 1315 as described herein. Thus, the use of these terms shouldnot be construed to limit the scope and breadth of the present inventionto the physical configurations described in these exemplary embodiments.

[0256] The cellular network is just one example of a technology that canbe used to implement the wireless communication feature of the presentinvention. In other embodiments, different types of wireless technologycan be used, such as low orbit or geosynchronous orbit satellitecommunications. In fact, any type of wireless technology can be used toprovide the wireless communication feature of the present invention.

[0257] Further, the Internet 1318 is used in a preferred embodiment ofthe present invention due to its wide use and availability. However, anytype of computer network can be used in alternate embodiments of thepresent invention. As such, the use of the examples of a cellularnetwork and the Internet 1318 should not be construed to limit the scopeand breadth of the present invention.

[0258] Details of the portable-computing device 1302 are depicted inFIG. 14. Typically, the portable-computing device 1302 comprises aclient computer 1404, a persistent storage device or database 1408, adisplay screen 1412, a keypad input device 1414, a speech interface1418, an ALI device 1406, a wireless transceiver 1402 and a telephonydevice 1410.

[0259] Note that these components, such as the ALI device 1406 and/orthe wireless transceiver 1402 may be imbedded within theportable-computing device 1302. Alternatively, such components may beimplemented as discrete external devices coupled to theportable-computing device 1302 through external ports, such as RS-232,SCSI, USB ports or the like.

[0260] In addition, many of the components described above are optionaland depend on each specific implementation of the present invention. Forexample, the speech interface 1418 and the ALI device 1406 are optionalcomponents. Embodiments of the present invention that operate without anALI 1406 accept manual input of location information via the keypad 1414or other input device.

[0261] Any type of general or special purpose computer system can beused to implement the portable-computing device 1302. Examples of suchdevices include standard laptop computers, automobile computers andpersonal digital assistant devices (PDAs). Typically theportable-computing device 1302 includes a CPU, local working memory, orRAM, non-volatile program memory, or ROM, and some form of non-volatileexternal memory for data storage 1408 such as any type of NVRAM, ormagnetic or optical disk storage systems. An example of ageneral-purpose computer system that can be used to implement thepresent invention is described below with reference to FIG. 22.

[0262] The display screen 1412 is used to display output from theportable-computing device 1302. The keypad device 1414 is coupled to theportable-computing device 1302 and is used for inputting data. Forexample, location data can be manually input from the keypad device1414.

[0263] In this example, a speech interface 1418 is also coupled to theportable-computing device 1302. The speech interface 1418 uses voicerecognition techniques to accept spoken commands from users forcontrolling the portable-computing device 1302. The speech interface1418 is used in a preferred embodiment to allow users to control thecomputer 1404 via spoken voice commands for promoting safe drivingconditions while operating the portable-computing device 1302 from anautomobile or the like.

[0264] The persistent storage device 1408 is used to store applicationprograms such as a web browser and one or more specialized applicationprograms used to implement the present invention as described in detailbelow. Such application program(s) is/are referred to herein as the “Go2Application program,” which is described in detail below. In addition,location and other information are stored as data packets on the localpersistent storage device 1408, as described in detail below. Dependingon the storage capacity of the persistent storage device 1408, one ormore database lookup tables can be stored therein and used fortranslating, for example, between a lat/lon coordinate system and theWGRS. However, all systems that are enabled in accordance with thepresent invention will generally have the capability to translatebetween a lat/lon coordinate system and the WGRS using the universaladdressing scheme as described above. Additional storage requirementsare needed to translate to and from the WGRS using proprietaryaddresses.

[0265] The wireless transceiver 1402 is used to send and receive databetween the portable-computing device 1302 and other devices such as theservers 1314 and 1315 coupled to the Internet 1318.

[0266] The ALI device 1406 is used to track the position, and possiblythe speed and bearing of the portable-computing device 1302. As statedabove, any device can be used that performs ALI functionality. Examplesof well-known ALI devices are GPS systems, low orbit satellite systems,geosynchronous orbit satellite systems, telephone number identificationsystems, cellular network triangulation methods, etc. In this example,telephone number identification systems (ANI) can be used in conjunctionwith a database lookup table to determine predefined fixed positions ofusers based on an assigned telephone number.

[0267]FIG. 15 is a block diagram depicting functional components of anapplication program or program(s) running on the portable-computingdevice 1302 in accordance with an embodiment of the present invention.As stated, the application program(s) is/are referred to herein as the“Go2 application program” 1500.

[0268] The Go2 Application program 1500 is provided with a web browsercomponent 1502. The web browser component 1502 is used to perform webbrowser functions for the portable-computing device 1302. In fact, inone embodiment, a standard web browser is used to implement the webbrowser component 1502 of the present invention. Alternatively,customized web browser code can be imbedded into the Go2 Applicationprogram 1500. In either case, the web browser module 1502 providesstandard web browser functions. Such functions would be apparent topersons skilled in the relevant art(s). As shown, the web browsercomponent 1502 is coupled to a web server 1510.

[0269] Accordingly, the web browser module 1502 interprets data streamssent from the server 1510 and displays text and/or graphics therefrom.The text and/or graphics are displayed on the display screen 1412. Theweb browser component 1502 also accepts input from users via the keypad1414 or other input devices. Preferably, the data streams transmitted bythe server 1510 are in a standard format, such as HTML, a modifiedversion of HTML or the like. In this fashion, generic web-browsing toolscan be used to interface with the web server 1510 and the U/I module1506 (see below) of the present invention.

[0270] The User Interface (U/I) module 1506 is coupled with the webbrowser module 1502. The U/I module 1506 is used to prompt the user forinformation including user preferences and category selections to beused for subsequent information requests, (i.e. on-line databasequeries) as described below. The U/I module 1506 preferably performs atleast some functions locally. That is, at least some functions providedby the U/I module 1506 are performed without a live connection to theserver 1510. These functions are referred to herein as “local functions”and are described in detail below. For example, one local functionprovides a menu that is displayed which allows users to select from alist of predefined categories. In this example, users select a categoryof interest for formulating a database query that is to be used in asubsequent on-line session with the primary server 1314. Details of thisaspect of the present invention are described below.

[0271] A data packet builder and parser module 1504 (hereinafter “datapacket module”) is coupled to the U/I module 1506. The data packetmodule 1504 is used to construct data packets, which are stored on thelocal storage device 1408. These data packets are subsequently read bythe server 1510 and used to formulate on-line database queries. The datapacket module also parses data packets received from the server 1510.Details and examples of data packet contents are described below.

[0272] An ALI polling module 1508 is used to poll the ALI device module1510. The ALI device 1406 provides location, bearing and speedinformation to the Go2 Application program 1500. This information isthen used to build data packets that are stored in the local datastorage device 1408. Details of a process that can be used to implementthe ALI polling module 1508 is described below.

[0273]FIG. 16 is a flowchart that generally describes an overall processin accordance with an embodiment of the present invention. The processbegins with step 1602. In step 1602 the process determines the currentlocation. The current location can be automatically determined from anALI device 1406, or can be manually input from the user. After thecurrent location is determined, control passes to step 1604.

[0274] Next, in step 1604, the process determines the desired locationand specific database query. The U/I module 1506 may be used to presentthe user with one or more selectable menu choices. Alternatively, in oneembodiment, the U/I module recognizes numerous requests based oncommonly used terms such as “burgers,” “shopping,” “banks,” or the like.In this fashion, the user can formulate a complex database query bysimply picking and choosing among the menu items presented or the usermay perform a simple database query by merely inputting one or morecommon terms.

[0275] For example, the user may wish to formulate a database query forfinding all fast-food restaurants within a five-mile radius. The desiredlocation may be different from the current location, if for example, theuser specifies some time in the future. For example, the user may wishto find fast-food restaurants within five-mile radius from a locationone hour in the future. In this example, the process can use the currentlocation, current speed and bearing to predict the desired location. Inanother example, a routing program can be used to determine the desiredlocation based on a pre-defined route input by the user.

[0276] Next, in step 1606, the desired location is converted to theWGRS, if necessary. For example, GPS devices typically use the geodeticlatitude and longitude system for describing location data. In this caseit may be necessary to convert to the WGRS in order to take advantage ofthe unique features of the referencing system as described herein.

[0277] In another example, a user may manually input locationinformation. Again, such manual input is preferably entered in the WGRSformat because of its ease of use lower susceptibility to errors. If Go2data is entered directly, either manually or by the ALI device 1406,then step 1606 is bypassed.

[0278] Next, in step 1608 the current location information and thedatabase query information is stored in the local storage device 1408.Typically, this information is stored in a pre-defined data formatreferred to herein as a “data packet.” The format of a typical datapacket is described below. Next, in step 1610, the portable-computingdevice 1302 connects to the primary server 1314.

[0279] In step 1611, the primary server 1314 reads the data packetstored in step 1608. From this information, a database query is formedas indicated by step 1618. Next, in step 1620, the process retrieves theresults from the database query and sends them to the client, asindicated by step 1620. The process ends with step 1622.

[0280]FIG. 17 is a flowchart depicting a process that can be used toimplement a portion of the Go2 Application software 1502. The processbegins with step 1702. In step 1702, the U/I module 1506 offers the userone or more options for specifying how location information is to bedetermined. Typically, if an ALI device is attached, it is used toautomatically provide location information to the Go2 Applicationsoftware 1500. Alternatively, one or more additional methods forspecifying location information are typically offered. In this example,as indicated by the block 1701, the user has the option to specify thatthe process retrieve location information from the attached GPSreceiver. In one example, the user can select between the current GPSlocation and a projected location based on a specified elapsed time.

[0281] In addition, predefined locations, such as home or office can bespecified. Typically, the location coordinates are pre-programmed as auser preference. In a preferred embodiment, the WGRS is used to specifysuch pre-programmed user preferences. Alternatively, in this example,the user can access a map in which to specify a location. The mapdatabase can either be provided locally by the client 1404, or can beprovided remotely through a connection with a server 1510.

[0282] In another example, a routing program (either on-line or locally)can be used to project future locations and to specify one or morewaypoints along a pre-defined route. In addition the user has the optionto manually specify location information. Advantageously, manual inputis in the form of the Go2 coordinate system.

[0283] It should be noted that block 1701 lists a few examples of thetypes of parameters that can be specified by users for determininglocation information in accordance with a preferred embodiment of thepresent invention. Alternate embodiments may comprise selections thatare very different from the examples provided herein. The actualcontents of menu items displayed by the U/I module 1506 depend on eachspecific implementation of the present invention. As such, the examplesused herein should not be construed to limit the scope and breadth ofthe present invention.

[0284] In any case, once location information is specified in step 1702,control passes to step 1703. In step 1703 the U/I module 1506 promptsthe user for criteria used to formulate a subsequent on-line databasequery. In this example, the user selects a category of interest, one ormore category features, a search radius and other selection criteria.One method that can be used to implement this step is to display aselectable menu to the user as shown in block 1704. The U/I module 1506is used to perform this function.

[0285] For example, the menu 1704 comprises category selections such as:restaurants; banks; ATM machines; hotels; copy centers; libraries;museums; gas stations; weather reports; car dealers; auto repair shops;maps; directory assistance; police stations; hospitals and the like. Inthis fashion, for example, the user can find nearby restaurants by firstselecting the corresponding category of interest, as shown in block1704.

[0286] In addition, the menu shown in block 1704 allows users to specifyone or more features associated with the selected category. Featureselections narrow or drill-down the subsequent database search. Forexample, the user may only be interested in restaurants that accept aparticular type of credit card, have a particular dress code, or providegoods within a particular price range. Accordingly, the user narrows thesubsequent database search by simply selecting one or more appropriatefeatures associated with the selected category. Multiple levels ofcategory features can be presented based on the needs and requirementsof each specific implementation of the present invention.

[0287] Another parameter that is preferably specified by the user is asearch radius. For example, the user can specify that the search onlyinclude points of interest within a particular radius from the currentor desired location.

[0288] It should be noted that these are just some examples of the typesof parameters that can be specified by users in accordance with apreferred embodiment of the present invention. Alternate embodiments maycomprise menu items that are very different from the examples providedherein. The actual contents of menu items displayed by the U/I module1506 depend on each specific implementation of the present invention. Assuch, the examples used herein should not be construed to limit thescope and breadth of the present invention.

[0289] Preferably, users can also define one or more user preferences.These user preferences are used as default parameters if they are notover-ridden by current selections. In this fashion, user input isminimized.

[0290] Once the database query parameters are specified, control passesto step 1705. In step 1705, the process determines whether the locationinformation is the WGRS format. If it is not, it is converted to theWGRS in step 1706. In one embodiment, this conversion takes placelocally. In another embodiment, the primary server 1314 performs theconversion upon connection with the client 1404. Next, in step 1707 adata packet 1708 is created. This data packet 1708 is then stored on thelocal storage device 1406.

[0291] In one example, the data packet comprises the followinginformation as depicted by block 1708. The current location, includingthe speed and bearing, if available. As stated, depending on thespecific implementation of the present invention, this may or may not bein the WGRS format. If it is not, the primary server can convert it intothe Go2 coordinate grid system.

[0292] As indicated by item 4, an estimate for an intended route, basedon an elapsed time may be included in the data packet. For example, auser may wish to stop for the night in one hour from the present time.In this example, an estimate of a future location may be included in thedata packet. The client 1404 or the server 1314, depending on eachspecific implementation of the present invention, can perform the futurelocation prediction. If the server 1314 performs the locationprediction, a time period is specified in the data packet 1708.

[0293] In addition, routing information may also be specified asindicated by item 5. A routing program or the like can provide thisinformation. If routing information is not given, a projected locationis determined based on the present position, speed and bearing. Ofcourse, if routing information is not provided, the server 1314 assumesthe user will remain on the current road for the specified elapsed time.Further, the server can use additional information, such as trafficand/or weather conditions to provide more accurate predictions. Thisadditional information can originate from anywhere on the Internet 1318or from an Intelligent Transportation System.

[0294] As indicated by item 6, predefined user preferences are alsoincluded in the data packet 1708. This can include, for example,information such as whether the user is on a business trip or onvacation. User preferences are used to further narrow the databasequery. For example, if the user is looking for hotel accommodations, theprogram can find appropriate selections based on whether the user is onbusiness or vacation. Preferably, the user preferences are entered onetime and are not changed for every database query to minimize inputrequirements.

[0295] Item 7 represents preferences that override predefined userpreferences for the duration of the next database query. Thus, forexample, a pre-defined user preference may be to find places or interestthat are within 5 miles. This user preference generally applies to everydatabase query. However, because the user is currently driving in arural area, the user may prefer to focus a search in a wider radius, say20 miles. The next time the user launches a database query, if theradius is not specified, it reverts back to the 5-mile user preferencevalue. Item 8 represents other database query parameters that may bepresent.

[0296] It should be noted that the above items that comprise the datapacket 1708 are just a few examples of the type of data that maycomprise a data packet in accordance with a preferred embodiment of thepresent invention. Alternate embodiments may comprise very differentdata items than the above examples. As such, the examples used hereinshould not be construed to limit the scope and breadth of the presentinvention.

[0297]FIG. 18 is a flowchart depicting a process that can be used toimplement a process performed by the primary server 1314 upon connectionwith the client 1404. Step 1802 represents a step where the client 1404connects with the server 1314. Next, in step 1804, the server 1314determines if a data packet 1708 is available on the client data storagedevice 1408. If a data packet is available, the location information isextracted therefrom, as indicated by step 1810. Control next passes tostep 1814, which is described below.

[0298] If it is determined in step 1804, that a data packet is notavailable, control passes to step 1806. In step 1806 the user is offeredan opportunity to download the Go2 Application software 1500. Next, asindicated by step 1808, control passes to step 1824 if the user acceptsthe offer to download the Go2 software 1500. In step 1824, the Go2Application software is downloaded to the client 1404.

[0299] Next, in step 1826, the Go2 Application software 1500 is executedon the client 1404. During the execution of the Go2 Application software1500, the user inputs user preferences, location specifications andother database query parameters, as described above. After suchinformation is entered, the Go2 Application software 1500 creates a datapacket 1708 and stores it on the data storage device 1408. After thisoccurs, control passes back to step 1802 as described above. Now theuser is enabled so that he or she can take advantage of the automatedfeatures of the present invention.

[0300] As indicated by step 1808, if it is determined that the offer todownload is rejected, control passes to step 1811. In step 1811, theuser is provided with one or more web pages that accept locationinformation, user preferences and the like in a manner similar to thatdescribed above with reference to the Go2 Application U/I module 1506.In this fashion, the primary server 1314 can provide services to usersthat are not enabled with the Go2 Application software 1500. Next, instep 1812, the primary server 1314 reads the location informationentered in step 1811. Control next passes to step 1814.

[0301] In step 1814, the location information, (either manually enteredin step 1811, or automatically extracted from the data packet in step1810), is converted to the WGRS, if necessary.

[0302] Next, in step 1814, the server 1314 performs a database query.The object of the database query is to find an appropriate server 1315that provides the type of service requested by the user. This aspect ofthe present invention is described in detail below, with reference toFIG. 19. The process ends as indicated by step 1822.

[0303]FIG. 19 is a flowchart and block diagram useful for describing theinteraction and processing between the client 1404, the primary server1314 and an enhanced server 1315. The process begins with step 1902. Instep 1902, the user selects a category of interest and other data fromthe menu 1701 as described above.

[0304] Next, In step 1904, the data packet module 1504 builds the datapacket 1708. The data packet 1708 is then stored on the local storagedevice 1408. Next, as indicated by step 1906, the data packet 1708 istransmitted to the server 1314. At this point the primary server 1314parses the data packet 1708 and formulates a database query on thedatabase 1316.

[0305] In accordance with one embodiment of the present invention, thepersistent storage device 1316 contains a list of the enhanced servers1315 that provide location specific information in accordance with thepresent invention. In particular, the primary server 1314 searches itsdatabase 1316 and retrieves a specific Uniform Resource Locator (“URL”)that satisfies the database search criteria entered by the user, asdescribed above.

[0306] It should be noted that the enhanced 1315 servers arepreprogrammed to provide data that is customized in accordance with aspecified location. Thus, the enhanced servers are preprogrammed toaccept and respond to a location identifier, preferably in the WGRS.

[0307] Next, in step 1912, the client 1404 receives a second data packet1914. The second data packet 1914 comprises the URL result from thedatabase query, plus any other additional information that may berequired by the enhanced server 1315, as specified in the database 1316.

[0308] Next in step 1916, the Go2 Application launches the web browsercomponent 1502 and automatically connects to the URL received in thedata packet. Specifically, the browser is programmed to accept the URLas the default page so that it is automatically loaded upon connectionto the Internet 1318.

[0309] It is noted that the present invention is described in terms of aprimary server 1314 and a plurality of enhanced servers 1315. In thisfirst embodiment, the primary server performs a database search thatresults in an address for an enhanced server that can satisfy thecustomer's database query. However, the present invention is notrestricted to this configuration. An alternative embodiment comprises aplurality of enhanced servers but no primary server.

[0310] For example, in one embodiment, the Go2 Application software 1500provides the services provided by the primary server 1314 in the aboveexample. In another embodiment, the user determines which one of theenhanced servers to connect to. In this example embodiment, each of theenhanced servers 1315 is preprogrammed to parse the data packet 1708 andextract location information therefrom, as described above.

[0311]FIG. 20 is a flow chart that is useful for describing a methodthat can be used in the Go2 Application program to implement a featureof the present invention for automatic location data collection. Theflowchart in FIG. 20 represents an endless loop and therefore has nodefined beginning or end point.

[0312] As indicated by step 2002, the process determines whether an ALIdevice 1406 is attached. If an ALI device 1406 is attached, controlpasses to step 2006. In step 2006 the ALI device 1406 is polled toretrieve location data therefrom. Next, in step 2010, the processdetermines whether the retrieved location data indicates a change fromthe previous poll. If step 2010 indicates that the location has notchanged (i.e. the user is not moving), control passes to step 2004,where the process sleeps for a predetermined time period until itrepeats itself in step 2002.

[0313] If step 2010 indicates that the location has changed, controlpasses to step 2012. In step 2012 the process determines if the client1404 is on-line. If so, control passes to step 2014. If the client isnot on-line, control passes back to step 2004.

[0314] In step 2014, the process determines if a server 1314 iscurrently requesting that location data be updated. The server in thisexample, can be any server, such as the primary server 1314 or anyenhanced servers 1315. If the server is requesting updated locationinformation, the current position, preferably in the WGRS format, istransmitted to the server in step 2016. If the server is not requestingan update, control passes back to step 2004.

[0315] As indicated by the blocks 2020 and 2024, the server uses the Go2location information for performing a database query. The results arethen sent back to the client and as indicated by block 2026.

[0316] An advantage of the present invention is that users can benefitfrom the virtually unlimited storage capacity and real-time updates ofthe Internet 1318. Because the Internet 1318 is used in a distributedfashion to provide users with customized location related information,the information provided to users can be as detailed as desired. Forexample, in addition to using maps to determine driving directions, moredetailed information, such as site plans, building floor plans,photographs of the destination, private road configurations and the likecan be presented to users.

[0317] In addition, because the direction in which the user is travelingcan be determined, that information can be used to select a properorientation for the extended information, such as a site plan, forexample. FIG. 21 depicts an example of a site plan that shows buildingconfigurations, parking lots, etc. In this example, the site plan inFIG. 21 is stored as digitized photograph. The orientation of thedigitized photograph displayed to the user depends on the user'sdirection of travel so that the proper orientation is displayed.

[0318] VII. Unified Geographic Database

[0319] An embodiment of a UGD will now be described, followed byexemplary methods of creating, maintaining, and using the same. The UGDis an automated, managed and secure database registry of location andlocation-based information provided by real-world businesses and otherentities, analogous to the registry of domain names for Internetaddresses and Web sites. As a location registry, the UGD is a commonrepository where businesses and other entities can post their locationand location-based information to make it available to potential users.In turn, users of the Internet and Web and other types of otherelectronic devices may query this registry to obtain accurate, completeand up-to-date location and location-based information about theregistered businesses and other entities.

[0320] The UGD will generally be described below in conjunction with abusiness entity and location-based information for that business.However, the UGD may include location-based information for entitiesother than a business such as, but not by way of limitation, non-profitorganizations, public facilities, specific events, etc., and alsoindividuals. In addition, the UGD is designed to provide location-basedinformation relevant to any users, including consumers, businesses,governmental, researchers, historians, etc.

[0321] The UGD will generally be described as operating on a singlecomputer for simplicity, although in practice it typically will bedistributed across multiple computers.

[0322] The UGD is a computerized database comprising numerous databaserecords, or entries, residing on a single or multiple database serverssuch as servers 1315 described above with respect to FIG. 13. Withreference to FIG. 22, an exemplary database record 2800 for a fictitiouslocation is shown. The record 2800 preferably includes a ULA address2802 and one or more PLA addresses 2804 (preferably having the sameprefix as the ULA, e.g., US.CA.IRV) to discretely identify the record2800 for accessing the same. In addition to the ULA/PLAs, the record2800 may generally include basic, static content such as a business' orother entity's name 2808 and address 2810. Additional static content mayinclude, but not by limitation, contact information (e.g., telephonenumber, facsimile number, e-mail address, Internet website address,wireless website address), what side of the street the business islocated on, e.g., North/South/East/West, the side of the street thataccess is not available from, a specific site map, an utility easementschematic, preferred routing to the location for deliveries vs.customers, routing from a specific highway intersection, and latitudeand longitude coordinates of the business location. The record 2800 mayinclude more rich, semi-static content such as, but not by way oflimitation, store hours, where to park, credit cards accepted, andinventory. The record 2800 may also include dynamic information such as,but not by way of limitation, movie times, specials, coupons, anddiscounts at a store. Real-time information such as, not by way oflimitation, inventories and auction prices, may also be located in therecord 2800. Finally, the database record 2800 may include one or moregeneric categories of business or other activity, e.g., pizza, cars,movies, as a non-exclusive secondary naming convention. These genericcategories may be used to refer users to specific business or otherentity locations based on a keyword search for such categories.

[0323] It should be noted, any of the data described above may not be inthe UGD, but instead replaced by a link in the UGD to that data. Thelink may be to other databases, information, or files where the data islocated. In other words, each record in the UGD may contain referencesto data pertaining to the entity associated with the PLA and locatedoutside of the UGD.

[0324] As mentioned, each record of the UGD is preferably keyed by ageocoded ULA, and one or more PLAs. The ULA/PLAs, especially the PLAs,are more user-friendly than those used in other geographical referencingsystems, which are based on arcane mathematical coordinate schemes,e.g., latitude/longitude or Universal Transverse Mercator coordinates.As described above, a ULA incorporates a place-naming hierarchy, and aPLA may additionally incorporate reserved names, phrases, orabbreviations as identifiers that allow users to quickly and easilyrefer to a desired business or other entity for purposes oflocation-based searching, direction finding, map-production andcommerce. For example, Johnny Rocket's™ Restaurant in Costa Mesa,Calif., has a PLA address of US.CA.COM.JOHNNYROCKETS and an abbreviated,mobile address of JROCK (in certain instances, the country, state andcity codes may be provided automatically). Because PLAs provide awell-defined, limited and structured notation, they facilitate bothtyped entry (e.g. easier to type “IRV.IHOP” than “International House ofPancakes, Irvine”) and voice recognition systems (e.g., easier to sayand interpret IRV.IHOP (IRV-DOT-IHOP) than 15412 MacArthur Boulevard,Irvine, Calif.). Famous brand name products, e.g., WHOPPER, BIG MAC, orpersonal phrases, e.g., MARYS HOUSE, DOUGS BARMITZVAH may also beincorporated in PLA addresses.

[0325] PLA addresses are as important to real-world businesses as domainnames are to e-businesses, because PLA addresses identify real-worldlocations and destinations for commerce just as domain names identifynetwork locations and destinations for e-business. The ULA/PLA,especially the PLA, provides both a discrete identifier for a business'record in the UGD, and a user-friendly naming convention and interfacefor all types of electronic devices—from web phones to car navigationsystems. Many of these devices have limited keypads, storage, displays,and bandwidth. Thus, the addition of ULA/PLA Addresses to records of theUGD enhances the value of the UGD by 1) providing the discreteidentifier and naming convention allowing specific locations to beeasily and precisely identified, 2) making it easier for users to findbusinesses and access their information, 3) providing a more accurate,real-time database of real-world locations and businesses, and 4)providing the infra-structure for coordinating the electronic executionof reservations, orders, purchases, and payments between real-worldbusinesses and their customers through Internet enabled portableelectronic devices. This, in turn, makes it more likely that users ofportable electronic devices will utilize the UGD for conductinglocation-based mobile commerce. A larger user base increases the utilityof the UGD to real-world businesses.

[0326] A. Creating the UGD

[0327] With reference to FIGS. 23-26B, exemplary methods for creatingthe UGD records will now be described. A UGD record is created byregistering with a registrar one or more proprietary addresses withlocation-related information such as that described above for a listingof a business or other entity. The location-related information isassociated and stored with a PLA address, which is utilized as adiscrete identifier for the record in the UGD.

[0328] Two exemplary methods will be described below for creating a UGDrecord. The first method relates to creating a UGD record by obtaining aproprietary name and location-related information for businesses throughan intermediary such as a Yellow Page Provider. The second methodrelates to creating a UGD record by obtaining the proprietary name andlocation-related information for businesses by a more direct method suchas through a web page over the Internet. Although two exemplary methodsare described for creating a UGD record, it will be readily apparent tothose skilled in the art that other methods exist.

[0329] The first exemplary method for creating a UGD record is to obtainthe location-related information for a business or other entity throughan intermediary such as Yellow Page providers (“YP Providers”). Otherintermediaries with more of an Internet presence that may be usedinclude web portals such as AOL™, Yahoo™. Currently, regional YPProviders sell advertising in physical and Internet Yellow Pages tobusinesses in their regional area of coverage. As a result, regional YPProviders have location-related databases for businesses in theirregion, but not other regions. Location-related information from thevarious regional YP Providers that together cover a desired geographicalarea, e.g., United States, may be transmitted to one or more centraldatabase servers such as servers 1315 described with respect to FIG. 13for central storage of the multiple records 2800 (FIG. 22) in the UGD.The one or more proprietary names for a business may be obtained orregistered by the YP Provider at the time the Yellow Pages advertisingis initially sold or renewed to the business. Depending on the type ofdata selected (static to dynamic), the UGD listing cost may vary.Further, as described above, the YP Provider may sell one or moregeneric names, e.g., pizza, cars, movies, as non-exclusive secondarynaming conventions that may be associated with a business' record sothat the record gets direct hits for appropriate keyword searches. IfPLA registration occurs at the time the advertising is sold/renewed,preferably some method of centralized PLA conflict checking such as thatdescribed below is performed by the central registrar so thatconflicting PLAs do not become stored in the UGD. Beforelocation-related information and one or more PLAs are stored as a UGDrecord, the street address of the business is geocoded and translatedinto an ULA address.

[0330] Central to the registry concept and process is generation andverification of a ULA from traditional address information, e.g. streetaddress, street intersection, public place name, etc. Conversion of suchtraditional, variable address information, based on names, which can beambiguous, into a fixed ULA, which is unambiguous, is known asgeocoding. With reference to FIG. 23, the geocoding process will now bedescribed in more detail. Geocoding is performed by a conversion engine2900. The conversion engine 2900 converts the street address from eachbusiness listing to an ULA address that may be used as a coordinateidentifier for each UGD record.

[0331] With reference to FIG. 24, at step 2902, the street address forthe business listing is converted into latitude/longitude globalcoordinates such as those in the World Geodetic System 1984 (WGS-84) byany well-known software application for converting street addresses tolatitude/longitude coordinates. Software applications for convertingstreet addresses to latitude/longitude coordinates are well-known in theart and, therefore, will not be described in any further detail. Itshould be noted, however, that the geocoding resulting from suchapplications are based on interpolations and extrapolations and thatvarious applications do not necessarily yield consistent results. Itshould also be noted that typically such applications charge a fee foreach conversion of a street address, so multiple users seeking toconvert the same street addresses to latitude/longitude coordinates(whether being used as a starting point or an intended destination) willcause repetitive conversions and, thus, unnecessary conversion fees.

[0332] Once the latitude/longitude coordinates of the street address aredetermined, at step 2904, the regional/local city reference gridcorresponding to the street address latitude/longitude coordinates isdetermined. In one method of determination, the street addresslatitude/longitude coordinates may be compared to a master list oflatitudes/longitudes of centroids or reference points for multiplereference grids, and the reference grid with the centroid or referencepoint closest to the latitude/longitude of the street address is thenchosen as the reference grid. For example, the latitude/longitudecoordinates for Go2 Systems, Inc. may be the following:latitude=33.6781, longitude=−117.8601. The reference grid with theclosest regional centroid to Go2 may be that of Costa Mesa, Calif.,i.e., US.CA.COM (Costa Mesa), and the nearest local centroid may be thatof Irvine, Calif., i.e., US.CA.IRV (Irvine).

[0333] Determination of the reference grid may be based or at leastpartially based on the grid corresponding to the city name of thelocation. For example, a location in Santa Ana may be given anidentifier based on Santa Ana even though it might be located closer tothe centroid for Costa Mesa.

[0334] At step 2906, the ULA is determined based on the location of thestreet address latitude/longitude coordinates within the regional grid.In an embodiment of the invention, the regional grid may be thought ofas a 100×100 km Cartesian plane, where the grid is subdivided into 10×10cells, each of which also may be thought of as a 10×10 km sub-plane.Using the centroid latitude/longitude as the reference origin, therelative location of the street address latitude/longitude in theregional grid is given by converted pairs of eastings and northings,where the first digit is the easting and the second the northing.Eastings may be thought of as being along the x-axis and northings maybe thought of as being along the y-axis. Once the appropriate 10×10 kmcell is located, that cell may in turn be thought of as 10×10 kmCartesian plane further subdivided into 10×10 sub-cells, each of 1×1 kmsize. Next, the eastings/northings for the relative location of thestreet address latitude/longitude in that sub-cell can be computed. Thisprocess continues up to the desired level of accuracy for the ULA hasbeen encoded, e.g., within 10 meters, 1 meter, etc. For example, the ULAaddress for Go2 Systems, Inc. (latitude=33.6781, longitude=-117.8601)may be determined to be US.CA.IRV.45.93.01.61.37. The “45” indicatesthat the initial 10×10 km cell occurs at easting 4 and northing 5 in the100×100 km grid. The “93” indicates that the next 1×1 km sub-cell withinthat cell is located at easting 9 and northing 3. The “01” indicatesthat the next 100×100 meter cell is located at easting 0 and northing 1.The “61” indicates that the next 10×10 meter cell is located at easting6 and northing 1. Finally, the “37” indicates that the 1×1 meter cell islocated at easting 3 and northing 7. Once the ULA is generated by thisprocess, or geocoded, it is verified and calibrated with respect to amap.

[0335] Geocoding, verification, and calibration is only performed oncefor a location; it is not repeated for subsequent uses of the location.With other systems, every time a user attempts to search in an area orobtain computer generated driving directions, street addresses aregeocoded through various geocoding engines (none of which work perfectlyor provide consistent geocoding), which is inefficient. After geocoding,verification, and calibration, the ULA is stored with the other businesslisting information as a record in the UGD, similar to the record 2800illustrated in FIG. 22.

[0336] The second exemplary method for creating a UGD record entailsobtaining the location-related information for a business or otherentity directly from the business or other entity over a communicationslink such as the Internet.

[0337] With reference to FIG. 25, the UGD creation method may bysupported by a client/server arrangement 3000 over a communications link3002 such as the Internet using the World Wide Web. The World Wide Web(“WWW”) allows a server computer system 3004, i.e., Web server or Website, to send graphical Web pages 3006 of information to one or moreremote client computer systems 3008. The remote client computer system3008 can then display the Web pages 3006. Each resource, e.g., computer3004 or Web page 3006, of the WWW is uniquely identifiable by a UniformResource Locator (“URL”). To view a specific Web page 3006, the clientcomputer system 3008 specifies the URL for that Web page 3006 in arequest, e.g., a HyperText Transfer Protocol (“HTTP”), HDML, WAP, etc.The request is forwarded to the Web server 3004 that supports the Webpage 3006. When the Web server 3004 receives the request, it sends thatWeb page 3006 to the client computer system 3008. When the clientcomputer system 3008 receives the Web page 3006, it typically displaysthe Web page 3006 using a browser 3010. A browser is a special-purposeapplication program that effects the requesting of Web pages and thedisplaying of Web pages.

[0338] The server system 3004 includes a server engine 3012 and one ormore databases 3014. The server engine 3012 receives HTTP requests toaccess Web pages 3006 identified by URLs and provides the Web pages 3006to the one or more client systems 3008 requesting the same. Anywell-known database software may be used to create and manage the one ormore databases 3014. As used herein, server system includes one or moreservers having any combination of hardware or software to implement theUGD record creation method discussed below. For example, but not by wayof limitation, the system 3004 may include a primary server with one ormore enhanced servers, e.g., mail server 3016, database server 3018,etc., to accomplish this purpose.

[0339] The client system 3008 may comprise any combination of hardwareor software that can interact with the server system 3004. Exampleclient systems include, but are not limited to, standard desktopcomputers, , standard lap-top computers, internet-enabled mobile phones,television-based systems, vehicle computers, personal digital assistantdevices (PDAs), internet-enabled computers, and other consumer productscapable of interacting with a server system 3004. Such client systems3008 preferably include a CPU, local working memory or RAM, non-volatileprogram memory or ROM, and may include some form of non-volatileexternal memory for data storage such any type of NVRAM, or magnetic oroptical disk storage.

[0340] It will be readily apparent to one skilled in the art that theUGD record creation method discussed below may be implemented in variousenvironments in combination with or other than the Internet. Forexample, as discussed in more detail below, the UGD creation system andmethod may be used in conjunction with an electronic mail environment inwhich information is transferred in an electronic mail message. Thecommunication link 3002 may include one or more of the following inaddition to, or instead of, the Internet: a local area network, a widearea network, point-to-point dial up connection, a wireless network, acellular network, a wired network, dedicated data lines, PersonalCommunications Systems (“PCS”), microwave, and a satellite network.

[0341] With reference to FIGS. 26A and 26B, an exemplary creation methodfor a UGD record by which a user directly registers a PLA andlocation-related information for a physical structure or geographiclocation with a registrar will now be described.

[0342] At step 3050, a user logs onto the server system 3004 of theregistrar(s), establishing a communication link. It should be noted thatuser may be an individual, a corporation, a partnership, a company, agovernment, or any other entity. The registrar is preferably a centralregistrar such as Go2 Systems. However, one or more delegated registrars(e.g., AOL™, Yahoo™) may be used. In the preferred embodiment, theserver system 3004 has a page on the World Wide Web, allowing the userto provide information through the interface of the Web browser 3010.However, as described above, the UGD record creation method discussedbelow may be used with other types of networks. When the user logs ontothe server system 3004, a home web page may appear with a variety ofinformation, including a link to another web page on the server system3004 to buy and register a business PLA, also known as a Go2Address™

[0343] At step 3054, when the user selects the link to buy a businessPLA, a new web page is accessed from the server system 3004, which mayrequest the user to input a PLA desired to be registered for acity/state.

[0344] At step 3056, after the above information is provided, thedesired PLA and the positional information (city/state) are submitted tothe server system 3004. The PLA and the positional information areassociated and stored on the server system 3004. In an alternativeembodiment, multiple PLAs may be entered for a location. For example, auser may want to register one or more PLAs related to the name of abusiness, e.g., BURGER KING, BK, and one or more PLAs related to brandnames for the business, e.g., WHOPPER.

[0345] At step 3058, the server system 3004 may perform a preliminarysearch or query for the PLA (for the city and/or state identified) inthe one or more databases 3014 of the server system 3004 to determine ifthe PLA is available, i.e., whether a conflict exists in the particularcity for the requested PLA. This may include formulating a databasequery based on the proprietary name(s) and at least one geographicallocation identified and issuing the database query. The server system3004 may include one or more automatic intelligent filters to determineif a conflict exists in the particular city for the requested PLA. Theone or more filters may be used, for example, to prevent theregistration of certain names, e.g., generic names, profanity,derogatory names, names that are registered trademarks, etc. The one ormore filters may be triggered during the formulation and issuance of thedatabase query. Alternatively, or in addition to the one or moreautomatic filters, as described in more detail below, manual subjectiveinput may be provided by the UGD central registrar to determine if aconflict exists for a desired PLA. A PLA may be automatically ormanually reserved on an international, country, state, city, or otherbasis.

[0346] To register multiple locations and/or reserve a PLA on the state,national, or international level, the user may be instructed to contactthe central registrar, or the process may be automated in a mannersimilar to that described above.

[0347] Preferably, a submitted PLA that is identical or similar to areserved PLA will be refused registration in the UGD. For example,McDonalds® may reserve MCD and MAC for McDonalds®. PLAs that are similarto these reserved PLAs, e.g., MACK, MACD, MACDONALD, etc., will berefused registration to prevent squatting practices. PLAs that arederivations of other PLAs, e.g., mcd.kids, mac.geo, macdonald.tv willalso be re fused registration. This, in essence, gives a company such asMcDonalds® more protection than they would get under the current domainname registration systems unless they register every potentialalternative. If one or more delegate registrars exist (e.g., AOL™,Yahoo™), the conflict or PLA availability checking is preferably done atthe central registrar. If a representative of a nationwide enterprisesuch as JIFFY LUBE□ wants to register the PLA “JIFFY LUBE” or anabbreviation of JIFFY LUBE□, i.e., “JLUBE” for all possible ULAlocations in the United States, a conflict search for the desired PLA inthe one or more databases 3014 for all of the PLA's in the United Statesmay be conducted. These locations in the form of a store list, includingstore street addresses (and possibly other related information such asstore hours, telephone number, etc.) for all the restaurants arepreferably electronically transmitted to the server system 3004 andstored in the one or more databases 3014 and assigned a pending statusuntil it is determined that a conflict with other PLAs does not existand payment has occurred.

[0348] Options may exist for the user to register one or more PLAs aspremium listings with richer, more dynamic data than the static datasuch as name, street address, and contact information. As with premiumlistings in the physical Yellow Pages, a customer/client may distinguishits business from that of others by highlighting its appearance in someway, and thereby offering users the ability to easily access informationabout the premium advertiser. Associated with this PLA, additionalinformation or links to additional information such as store hours,number of years experience, types of products or services, etc. may bestored in the UGD record. Depending on the type of data selected (staticto dynamic), the listing cost may vary. Further, as described above, thebusiness or other entity may purchase or obtain with registration one ormore generic categories, e.g., pizza, cars, movies, as non-exclusivesecondary naming conventions that may be associated with a business'record so that the record is readily identifiable in appropriate keywordsearches.

[0349] In an alternative embodiment of the invention, a PLA availabilitysearch for multiple locations on the state, national, or internationallevel may be automatically accomplished via a web page 3006 similar tothat described above. For example, the web page 3006 and server system3004 may allow for a search or query at levels higher than the citylevel. To effect this, in part, the web page may also allow for locationinformation higher than the state/province level to be input, e.g.,country, international. The server system 3004 may be configured so thatit searches in accordance with the most detailed level of locationinformation input by the user (if city information is provided, theserver system 3004 will search at the city level, if city information isnot provided, but state information is provided, the server system 3004will search at the state level, etc.) For example, if the user wants tocheck whether a PLA is available for multiple locations on a nationallevel such as in the JIFFY LUBE□ example above, the user could input USor United States in a country field on the web page without entering anyinformation in the city or state fields. This would cause the serversystem 3004 to formulate and issue a database query for the desired PLAin the one or more databases 3014 against all of the PLA's in the UnitedStates to determine if and where the name is available in the UnitedStates. If a conflict was not found, one or more web pages may beprovided by the server system 3004 instructing the user how to downloadthe location information (and possibly other related information such asstore hours, telephone number, etc.) for all the locations for the PLAto the server system 3004 to be stored in the one or more databases3014.

[0350] At step 3062, if a conflict does exist, a web page from theserver system 3004 may indicate a conflict.

[0351] The user may stop the registration process at this point or addthe requested information for a different PLA and search the one or moredatabases of the server system 3004 to determine if a different PLA isavailable (step 3058).

[0352] At step 3066, if a conflict does not exist, a web page from theserver system 3004 may indicate so.

[0353] At step 3070, the user may proceed to register, accessing a newweb page from the server system 3004, which may request from the user toprovide the location-related information such as that described aboveand other registration-related information, e.g., credit cardinformation. The user may provide the requested information by directweb page entry. In an alternative embodiment of the invention, some orall of the above information may be provided automatically. For example,the location information requested above may be supplied by an automaticlocation device such as ALI device 1406 described above. Also, massregistrations of multiple locations for one or more PLAs may be donethrough an automated process of downloading a file or the like.

[0354] At step 3072, the user transmits the user and payment informationto the server system 3004. The PLA, and location-related data, andpayment information may be stored along with a pending status indicationin respective data fields in a pending or holding database 3074 on adatabase server of the server system 3004.

[0355] At step 3078, an email or other message server of the serversystem 3004 preferably sends an email or other message to the user atthe email address provided to confirm registration. The user may berequested to reply to the email to confirm that registration wasdesired. If the user does not reply to the confirmatory email, the userinformation, payment information, PLA, and geographic locations may bemaintained in the pending or holding database of the database server ofthe server system 3004 in a pending status condition, and paymentprocessing may be put on hold until confirmation is received. If theuser replies to the confirmatory email, control may be passed on to thenext step.

[0356] At step 3082, credit card payment processing may occur by theserver system 3004 in any well-known manner. If a problem occurs inpayment processing, at step 3086, the user may be notified accordinglyvia an email or message sent by an email or message server of the serversystem 3004 and the user information, payment information, PLA, andgeographic location information may be maintained in the one or moredatabases 3074 on the server system 3004 in a pending status conditionuntil authorization or other payment conditions occur. If paymentprocessing occurs without any problems, or if any problems arecorrected, control may be passed on to the next step.

[0357] In a preferred embodiment of the invention, to further ensurethat a desired PLA is available, a step 3090 may be performed. At step3090, an automatic email or other message may be sent from a email orother message server 3016 (FIG. 25) of the server system 3004 to one ormore UGD registrar computer systems 3094, indicating that approval issought for the particular PLA. The one or more registrar computersystems 3094 preferably include custom interface software that allows arespective operator of the one or more computer systems to accept orreject registration of the particular PLA. A final conflict check forthe desired PLA is performed to ensure that a conflict does not existbetween the desired PLA and one or more existing or potential PLAs. Itmay be determined, for example, that the desired PLA may conflict with apotential PLA such as a registered trademark of a company and, thus,providing a basis for refusing registration of the desired PLA. If anoperator rejects the registration of the desired PLA via the interfacesoftware, at step 3092, an email or other message indicating that aconflict exists or the like may be sent to the user via the email server3016 of the server system 3004, and the user may be prompted to selectanother PLA at step 3058. If a conflict does not exist, the individualaccepts the registration of the desired PLA via the interface software.This may cause, at step 3098, an automatic email or message to begenerated by the server system 3004 and sent to the user indicating thatregistration has been accepted and that the registered PLA is nowactive, and control may be passed on to the next step.

[0358] In an alternative embodiment of the invention, instead of apreliminary availability check 3058 and a final availability check 3090,only a single PLA availability check may be performed.

[0359] At step 3102, the above-mentioned location information may begeocoded to an ULA address, verified and calibrated as described abovewith respect to FIGS. 23 and 24. The ULA, PLA(s), and locationinformation for the business may then be stored. After geocoding, therecord data may be updated to an active status, making PLA andlocation-related data for the business selectively accessible to usersof locational systems via the Internet. The above-mentioned data couldbe converted to an active status by, for example, changing the statusfield for the above-mentioned data from a pending status to an activestatus or by transferring the above-mentioned data to another database,e.g., an active status database, in the same or a different server.

[0360] A method for registering a free personal Go2 Address□ or PLA withlocation-related information for an individual, non-profit organization,etc. may occur in a similar manner.

[0361] The UGD record creation method described immediately aboveprovides a direct, easy and convenient way for geocoding and registeringa PLA for each of the geographical locations of a business or otherentity, thereby creating records for them in the UGD. The resulting UGDis sortable and selectively downloadable by users of locational systemssuch as the client computer system 3008 via the Internet. It will bereadily apparent to those skilled in the art that one or more of thesteps of the PLA registration method described above with respect toFIGS. 26A and 26B may be eliminated or replaced with one or more relatedsteps without departing from the spirit and scope of the invention.

[0362] Although the UGD has been described as being centralized, inalternative embodiments of the UGD, the UGD may be de-centralized andlocated on different servers, e.g., part on Go2™ servers and part on,for example, AOL™ and/or Yahoo™ servers. Different types of data of theUGD may be located in different locations, e.g., static UGD data may belocated on AOL™ and/or Yahoo™ servers and dynamic UGD data may belocated on Go2™ servers. Alternatively, all or a portion of the UGD maybe located closer to the user, on one or more carrier gateways, e.g., onAOL™ and/or Yahoo™ servers, or one or more wireless carrier platformgateways, or downloadable into a device.

[0363] B. Maintaining the UGD

[0364] The UGD is maintained up-to-date by the UGD registrar in nearreal-time in order to ensure its accuracy and completeness. Thisupdating directly benefits registered businesses because it allows themost current location-based information, including in particular new(and changed) store locations, as well as topical information such asstore hours and in-store promotions, to be accessible to customers viathe UGD. By contrast when a store changes its location or its phonenumber, its physical Yellow Pages listing may be out-of-date for up to ayear, until the book is reprinted in toto. With the UGD's up-to-dateinformation and directional capabilities, registered businesses knowthat users of the UGD will be able to find their locations and otherinformation about them easily and quickly from a single source. Forinstance, if a franchise-business operator such as McDonald's®, opens 30new stores per month, it can utilize the UGD to distribute thatinformation to all users of web-enabled devices immediately—a resultwhich is impossible for McDonald's® to achieve today. As describedabove, physical Yellow Pages books are typically updated annually. Thenear real-time nature of the UGD also benefits users because they willalways know they can access one source to find the most up-to-dateinformation on any business' location, new locations, stores hours, etc.The UGD can be utilized to distribute rich information (e.g., real-timespecials, discounts, coupons, current travel instructions based oncurrent traffic conditions, a parade, a special event, or roadconstruction, etc.) to all or select (e.g., geographically relevant)users of web-enabled devices immediately. This may be done at the store,district or regional, or national office level.

[0365] Use of PLAs, rather than the ULA, to identify UGD records isadvantageous because even in the event of a changed location,information in the UGD may be updated without interruption. The ULA, bycontrast, changes when a business', or other entity's, physical addresschanges. This feature allows the necessary frequent updating of UGDrecords—especially those for a large company's such as McDonald's®—to bemade transparently to users of the UGD. An advantage of both PLAs andULAs is that both can be used consistently across all types of platforms(e.g., wireless web-enabled devices, car navigation systems, desktops,etc.)

[0366] In an embodiment of the invention, a business or other entity maychange the location-related information in their UGD record nearreal-time via a Web interface similar to that described above forregistering a PLA (creating a UGD record).

[0367] C. Using the UGD

[0368] With reference to FIG. 27, a UGD 4000 resides on one or morecomputer data servers 4010, and information therein is sortable andselectively downloadable over a network communication link 4020, such asthe Internet, by users of a wide variety of client access devices 4030(e.g., online Internet, wireless, voice 411 directory assistance, voiceactivated portals). For this purpose, the ULA/PLA address serves as thediscrete identifier to access location-related information in the UGD4000.

[0369] The UGD 4000 may be centralized or distributed. (A centralizedconfiguration is described above, and below, for simplicity.) Ingeneral, database distribution provides system performance benefits ofreliability and scalability, at the expense of system complexity. Evenwhen the UGD 4000 is distributed, a centralized version of the (same)UGD 4000 may be retained. The central UGD 4000 is also referred to asthe Master UGD; distributed copies/portions of the UGD 4000 are referredto as Slave UGDs. In a distributed configuration the Master and SlaveUGDs must be synchronized in varying degrees and manners according tothe database management software used to implement them.

[0370] In both centralized and distributed configurations, UGDMaster/Slave databases 4000 are maintained by transactions againstindividual records: additions, updates, and deletions. In general, thesetransactions are initiated by the business requirements, and entailancillary checks to ensure database integrity when they occur, so thatthe UGD 4000 remains accurate, complete, and up-to-date at all times.

[0371] The intention of the UGD 4000 is to facilitate navigation andcommerce by providing real-world location information on demand acrossnetwork communication links, in both wired and wireless environments.With easy access to such information, both simplifications andenhancements of current location-based practices, as well as entirelynew practices, are possible. The key in all cases is identifying andretrieving relevant information from the UGD 4000, based on the user'sactual and/or planned location(s).

[0372] Associated with the UGD 4000 is one or more Location Name Servers(LNSs) that allow geocoding of colloquial place names and addresses intoULA/PLAs, and retrieval of UGD information according to these ULA/PLAs.One or more LNSs 4040 include a geocoding conversion engine 4050 similarto conversion engine 2900 described above with respect to FIG. 23 thatserve the geocoding function. Just as Domain Name Servers support theInternet and Web in resolving a domain name (e.g. go2online.com) into anIP address (e.g. 165.32.43.44), LNS facilitates use of computer networksfor location-based activity, by resolving colloquial addresses toreal-world locations and symmetrically by resolving ULA/PLAs back toreal-world street addresses (reverse geocoding). Since the ULA/PLAs areexplicitly formatted they can be rapidly parsed; since they arehierarchical in nature, they permit efficient partitioning and indexingof the UGD 4000 as well.

[0373]FIG. 27 illustrates how the UGD 4000 (on a database server 4010)and the geocoding engine 4050 (on a LNS 4040) may be combined in a Tier2 level server configuration for communication with one or more clientdevices 4030. FIG. 28 illustrates how the UGD 4000 and the geocodingengine 4050 may be combined (on a combined server ) in a Tier 1 levelserver configuration for communication with one or more client devices4030.

[0374] Conventionally, real-world locations are identified andreferenced by physical address: place names, street addresses,cross-streets, and the like. Such places can be searched sequentially inthe UGD 4000, with limited reliability. A much more efficient approachis to geocode them on the LNS 4040 via WGRS into ULA/PLAs that can beused to access the UGD 4000 directly. Thus, the UGD 4000 may be queriedin several different ways to access location-based information. Someexamples of these include:

[0375] ξ Physical Address Query

[0376] The UGD 4000 may be queried using conventional physical addressinformation. This is the least efficient method as ambiguities inaddress spelling; punctuation and phonetics allow for infinitevariations in interpretation and ultimately introduce delayed responses.

[0377] ξ PLA Query

[0378] The UGD 4000 may be queried using registered PLAs. Since validPLAs are known a priori, and referenced to single or multiple locationsvia ULAs (below), this is an efficient and reliable method for accessingthe UGD 4000 for lists of location-based information, where elements ofthe list share a common registration, i.e. proprietary place name.

[0379] ξ ULA Query

[0380] The UGD 4000 may be queried using registered ULAs. Depending onthe specified granularity, the ULA may be used as an extremely efficientmethod for accessing the UGD 4000 for a single instance oflocation-based information or at varying levels of granularity.

[0381] ξ Traditional Latitude/Longitude Query

[0382] The UGD 4000 may be queried using standard WGS-84latitude/longitude values. Since a latitude/longitude values pair isinter-convertible with a ULA, at a specified precision, this amounts toULA query (above) in an alternate form. This option is provided forcompatibility with many existing software packages that deal with globalpositioning systems (GPS), geographic information systems (GIS) and thelike.

[0383] The specific mechanism of UGD access, supporting all four ofthese modes, and possibly others, will now be described. A web browser4070 on the client 4030 may include software for understanding a WorldGeographic Referencing Protocol to facilitate accessing the UGD 4000.This would allow a browser to forward ULA/PLA related queries andrequests to an appropriate LNS or UGD registrar. For example, the worldwide web (“web”) is a service universally recognized by web browsers.The content of web pages is typically provided to a web browser in theHyper Text Markup Language (“HTML”). Delivery of the HTML content usesthe Hyper Text Transport Protocol.

[0384] Similarly, web browsers recognize additional services other thanthe world wide web. For example, file transfer services are recognizedin addition to remote access services. These different services areindicated in the structure of requests submitted in a web browser. Forexample, three such requests may look like the following:

[0385] http://www.domain.name

[0386] ftp://ftp.domain.name

[0387] telnet://telnet.domain.name

[0388] In all of the above examples, the service is identified by thelabel preceding the “://” separator. This allows the web browser toresolve the IP address of the recipient (via DNS) and send the requestto the appropriate corresponding service on the recipient. So the webservice request would be sent to the IP address corresponding to thedomain name www.domain.name. The file transfer service request would besent to the IP address corresponding to the domain name ftp.domain.name.And the remote access service request would be sent to the IP addresscorresponding to the domain name telnet.domain.name.

[0389] The service at the receiving end is identified by resolving theservice identifier to a well-known port number for that particularservice. For example, web services are universally assigned to port 80.Such assignments are well known to those skilled in the art, and cantypically be found configured in a services file on the computer hostingthe requested information.

[0390] Advantageously, this scheme may be employed to construct queriesfor the UGD. For example, a structure for a UGD query within a webbrowser may be:

[0391] wgrp://us.ca.irv.go2

[0392] In such a case, the wgrp label may identify the ULA/PLA addresslookup request. A web browser properly configured may respond to such aquery by providing the ULA/PLA address to the appropriate LNS or UGDserver.

[0393] For example, typing in a PLA address request such aswgrp://us.ca.irv.go2 on a web browser will display information aboutGo2's physical location from the UGD 4000, analogous to typing in a webaddress to reach the web property. Once such a spatial reference ismade, then higher-order portions of the ULA/PLAs are “remembered” as astarting point for subsequent references, until over-ridden. Thus,wgrp://go2 and wgrp://IHOP, could be used as shortened notations for Go2and International House of Pancakes in Irvine, Calif., respectively. Ingeneral, it may be desirable to preset the ULA/PLA of a well-knownlocation as a starting point for references and searches. This startingpoint may be prompted from the user, or selected from a list offrequently-used starting points, known from prior usage; or it may bedetermined transparently by

[0394] Patent automatic location identification (ALI) technology in somedevices. Even with ALI, remote ULA/PLAs may be specified to establish astarting point for references and searches.

[0395] In an embodiment of the protocol, typing in keywords such aswgrp://hotels may cause the browser to function as if this word wastyped in a search engine. This will return a set of local hotels. If auser has not designated a starting point yet, and the device is not ALIcapable, the user may first be prompted with a pop up window or websitewhere the user may log onto the website, enter a street address, or Go2address as a starting point.

[0396] In another embodiment of the protocol, typing in retailerspecific brand names such as bigmac, or whopper, may return a list oflocations from the UGD that have those words associated with them. Forexample, entering wgrp://bigmac may return a list of local McDonalds®stores, entering wgrp://whopper may return all Burger King® locations.

[0397] Queries received by a web browser may be communicated to the UGDor an LNS in a standardized format . A method for sending a query insuch a standard format will now be described. The standard format may bebased on the eXtensible Markup Language (XML), which may be controlledby W3C (the World Wide Web Consortium).

[0398] An exemplary Go2 query transaction may include accessing a LNS orthe UGD from a client by formatting the appropriate query and placing itwithin an agreed upon transport mechanism. The LNS or the UGD willattempt to perform internal database searches for the request and returnthose records to the requestor. In the case where a LNS attempts tohandle the query, if the LNS is unable to respond, it may submit thequery to the UGD for fulfillment.

[0399] With reference to FIG. 29, in an exemplary Go2 query transactionfor retrieving information from records in the UGD, the query data isfirst received from the requestor, as illustrated in step 4500. Thequery data is preferably entered by the requester through a web pageinterface. In an alternative embodiment, the query data may be receivedusing a message service such as electronic mail. The query may becomprised of a plurality of data elements, including a client ID,transaction ID, listings request data, search radius (in miles orkilometers), search type, search value, and a starting location. Thequery may also include one or more of the enumerated query typesdiscussed above (i.e., physical address, PLA, ULA, latitude & longitude)

[0400] Once the query data has been received, the data is formatted intoan appropriate request, as shown in step 4510. In one embodiment, therequest may be formatted using XML. Alternatively, requests may beformatted using HTML or any other high level programming language orinterpreted language such as Perl.

[0401] Upon formatting the request into a proper query, the query issubmitted to a server for processing, as seen in step 4520. The querymay be submitted directly to the UGD or alternatively to a LNS.Advantageously, the use of a LNS can decrease the workload on the UGDand improve communication speeds for queries and registrations alike. Aquery may be submitted to the server using the standard http transportprotocol. For example, the query data may be posted to a URL specifiedby Go2 Systems and known to the browser. Alternatively, the query may besubmitted to the server using a wgrp protocol. In one embodiment, thewgrp protocol may be optimized for delivering Go2 queries and responses.

[0402] The server receives and parses the query, as illustrated in step4530. Additionally, the server may validate the query based on a clientidentifier or other data element employed to verify the authenticity orpriority of the query. Similarly, the server may process the query basedon a type identifier or other identifier that may advantageously narrowthe scope of the query to a particular subset of the UGD database.

[0403] Once the query has been received and parsed and otherwisevalidated and processed, the server can execute the query in thedatabase, as shown in step 4540. In one embodiment, if the search isconducted by a LNS and the search does not return any results, the LNSmay forward the query to the master UGD for an authoritative response tothe query. For example, the LNS may receive no results from a query whenthe LNS locally maintains a partial subset of the complete UGD database.The corresponding results from the search can then be sorted by theserver, as seen in step 4550. Advantageously, the results of the searchcan be sorted according to their geographical proximity to therequestor.

[0404] Once the results of the query have been received and sorted, theresults may be formatted before being returned to the requestor, asshown in step 4560. In one embodiment, the results of the query may beformatted in XML for presentation using an XML enabled browser.Alternatively, the results may be formatted using HTML or some otherequally displayable format. After formatting the results, the resultscan be sent to the requester, as illustrated in step 4570. As indicatedabove, the format for the transmission of the response may include http,wgrp, or any other communication protocol capable of data transport overa communications network.

[0405] The UGD and other aspects described above in sections I-VI may beimplemented using hardware, software or a combination thereof and may beimplemented in one or more computer systems or other processing systems.In fact, in one embodiment, the invention is directed toward one or morecomputer system capable of carrying out the functionality describedherein. An example computer system 2201 is shown in FIG. 30. Thecomputer system 2201 includes one or more processors, such as processor2204. The processor 2204 is connected to a communication bus 2202.Various software embodiments are described in terms of this examplecomputer system. After reading this description, it will become apparentto a person skilled in the relevant art how to implement the inventionusing other computer systems and/or computer architectures.

[0406] Computer system 2202 also includes a main memory 2206, preferablyrandom access memory (RAM), and can also include a secondary memory2208. The secondary memory 2208 can include, for example, a hard diskdrive 2210 and/or a removable storage drive 1012, representing a floppydisk drive, a magnetic tape drive, an optical disk drive, etc. Theremovable storage drive 2212 reads from and/or writes to a removablestorage unit 2214 in a well-known manner. Removable storage unit 2214,represents a floppy disk, magnetic tape, optical disk, etc. which isread by and written to by removable storage drive 2212. As will beappreciated, the removable storage unit 2214 includes a computer usablestorage medium having stored therein computer software and/or data.

[0407] In alternative embodiments, secondary memory 2208 may includeother similar means for allowing computer programs or other instructionsto be loaded into computer system 2201. Such means can include, forexample, a removable storage unit 2222 and an interface 2220. Examplesof such can include a program cartridge and cartridge interface (such asthat found in video game devices), a removable memory chip (such as anEPROM, or PROM) and associated socket, and other removable storage units2222 and interfaces 2220 which allow software and data to be transferredfrom the removable storage unit 2222 to computer system 2201.

[0408] Computer system 2201 can also include a communications interface2224. Communications interface 2224 allows software and data to betransferred between computer system 2201 and external devices. Examplesof communications interface 2224 can include a modem, a networkinterface (such as an Ethernet card), a communications port, a PCMCIAslot and card, etc. Software and data transferred via communicationsinterface 2224 are in the form of signals which can be electronic,electromagnetic, optical or other signals capable of being received bycommunications interface 2224. These signals 2226 are provided tocommunications interface via a channel 2228. This channel 2228 carriessignals 2226 and can be implemented using wire or cable, fiber optics, aphone line, a cellular phone link, an RF link and other communicationschannels.

[0409] In this document, the terms “computer program medium” and“computer usable medium” are used to generally refer to media such asremovable storage device 2212, a hard disk installed in hard disk drive2210, and signals 2226. These computer program products are means forproviding software to computer system 2201.

[0410] Computer programs (also called computer control logic) are storedin main memory and/or secondary memory 2208. Computer programs can alsobe received via communications interface 2224. Such computer programs,when executed, enable the computer system 2201 to perform the featuresof the present invention as discussed herein. In particular, thecomputer programs, when executed, enable the processor 2204 to performthe features of the present invention. Accordingly, such computerprograms represent controllers of the computer system 2201.

[0411] In an embodiment where the invention is implemented usingsoftware, the software may be stored in a computer program product andloaded into computer system 2201 using removable storage drive 2212,hard drive 2210 or communications interface 2224. The control logic(software), when executed by the processor 2204, causes the processor2204 to perform the functions of the invention as described herein.

[0412] In another embodiment, the invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASICs). Implementation of the hardwarestate machine so as to perform the functions described herein will beapparent to persons skilled in the relevant art(s).

[0413] In yet another embodiment, the invention is implemented using acombination of both hardware and software.

[0414] While embodiments and applications of this invention have beenshown and described, it would be apparent to those in the field thatmany more modifications are possible without departing from theinventive concepts herein. The invention, therefore, is not to berestricted except in the spirit of the appended claims.

We claim:
 1. A method of creating a Unified Geographic Database (UGD) byregistering a proprietary name for a geographical location of an entity,the method comprising: receiving geographical location information foran entity; receiving a proprietary name for the entity; geocoding thegeographical location information into a hierarchical address; storingthe proprietary name, hierarchical address, and geographical locationinformation as a record in the Unified Geographic Database.
 2. Themethod of claim 1, wherein the proprietary name and the hierarchicaladdress serve as alternate keys for accessing the record in the UGD. 3.The method of claim 1, wherein the proprietary name is registered for ageographical location with a central registrar through an intermediary.4. The method of claim 1, wherein the proprietary name is registered fora geographical location directly with a single, central registrar over acommunications network.
 5. The method of claim 1, wherein theproprietary name is registered for a geographical location with acentral registrar and one or more additional registrars.
 6. The methodof claim 5, wherein static location-related data for a registeredproprietary name is stored with the one or more additional registrarsand dynamic location-related data for a registered proprietary name isstored with the central registrar.
 7. The method of claim 1, whereinstatic location-related data for the entity is stored in the record. 8.The method of claim 1, wherein dynamic location-related data for theentity is stored in the record.
 9. The method of claim 1, whereinreal-time location-related data for the entity is stored in the record.10. The method of claim 1, wherein a link to location-related data forthe entity located outside the record is stored in the record.
 11. Themethod of claim 1, wherein location-related data including one or moregeneric categories that relate to the nature of the entity is stored inthe record.
 12. The method of claim 1, wherein the proprietary name isan entity name or an abbreviated version of an entity name.
 13. Themethod of claim 1, wherein the proprietary name is a brand name or anabbreviated version of a brand name that serves as an identifier of theentity as one of the entity's branded products or services.
 14. Themethod of claim 1, wherein the step of obtaining a proprietary nameincludes obtaining multiple proprietary names for the geographicallocation of the entity.
 15. The method of claim 1, further includingconflict checking the proprietary name against other proprietary namesto ensure a conflicting name is not registered.
 16. The method of claim1, wherein geographical location information includes a street addressor latitude/longitude coordinates, the hierarchical address is a WorldGeographic Referencing System (WGRS) universal locational address, andgeocoding includes converting the street address or latitude/longitudecoordinates to the universal locational address based on the WGRS. 17.The method of claim 16, wherein geocoding includes converting the streetaddress to latitude/longitude coordinates, and further converting thelatitude/longitude coordinates into the universal locational address.18. The method of claim 16, further including verifying and calibratingthe universal locational address.
 19. The method of claim 18, whereinthe geocoding, verifying and calibrating is performed only once for ageographical location.
 20. The method of claim 1, further includingfrequently updating the location-related data for an entity based on itsproprietary name without changing the proprietary name, so that the datais current, accurate, and complete.
 21. The method of claim 1, furtherincluding converting the proprietary name into a domain-name like,proprietary locational address based on the geographical locationinformation, the proprietary name, and the World Geographic ReferencingSystem (WGRS), and storing the proprietary locational address as theproprietary name in the record.
 22. The method of claim 21, whereinconverting the proprietary name into a domain-name like, proprietarylocational address includes determining a regional or local grid havinga centroid closest to the geographical location of the business orentity, the regional grid represented by an A.B.C naming format, where Arepresents a country, B represents a state or province, and C representsa city, and prefixing this A.B.C format to the proprietary name tocreate the domain-name like proprietary locational address.
 23. A methodof creating a unified geographic database (UGD) by registering aproprietary name for a geographical location of an entity, the methodcomprising: receiving geographical location information for an entity;receiving a proprietary name for the entity; storing the proprietaryname and geographical location information for the entity as a record inthe Unified Geographic Database.
 24. The method of claim 23, furtherincluding converting the proprietary name into a domain-name like,proprietary locational address based on the geographical locationinformation, the proprietary name, and the World Geographic ReferencingSystem (WGRS), and storing the proprietary locational address as theproprietary name in the record.
 25. The method of claim 24, whereinconverting the proprietary name into a domain-name like, proprietarylocational address includes determining a regional or local grid havinga centroid closest to the geographical location of the business orentity, the regional grid represented by an A.B.C naming format, where Arepresents a country, B represents a state or province, and C representsa city, and prefixing this A.B.C format to the proprietary name tocreate the domain-name like proprietary locational address.
 26. Themethod of claim 23, wherein the proprietary name serves as a discreteidentifier for accessing the record in the UGD.
 27. The method of claim23, wherein the geographical location information includes a streetaddress or latitude/longitude coordinates, and the method furtherincludes geocoding the street address or latitude/longitude coordinatesinto a World Geographic Referencing System hierarchical universallocational address and storing the universal locational address with theproprietary name in the entity record.
 28. The method of claim 27,wherein geocoding includes converting the street address tolatitude/longitude coordinates, and further converting thelatitude/longitude coordinates into the universal locational address.29. A method of creating a Unified Geographic Database (UGD) byregistering a universal location address (ULA) for a geographicallocation of an entity, the method comprising: receiving geographicallocation information for an entity; geocoding the geographical locationinformation into a ULA based on the World Geographic Referencing System(WGRS); storing the ULA and geographical location information as arecord in the Unified Geographic Database.
 30. The method of claim 29,wherein geographical location information includes a street address orlatitude/longitude coordinates, and geocoding includes converting thestreet address or latitude/longitude coordinates to the ULA.
 31. Themethod of claim 29, wherein geocoding includes converting the streetaddress to latitude/longitude coordinates, and further converting thelatitude/longitude coordinates into the universal locational address.32. The method of claim 29, further including receiving a proprietaryname for the entity and storing the proprietary name with the ULA andgeographical location information in the record.
 33. A method of using aunified geographic database (UGD) containing records for multipleentities referenced by a World Geographic Referencing System (WGRS)address and returning location-related information for the entities, themethod comprising: receiving a WGRS address; accessing on or more entityUGD records based on the WGRS address; providing location-relatedinformation from the one or more entity UGD records accessed.
 34. Themethod of claim 33, wherein the WGRS address is a proprietary locationaladdress (PLA).
 35. The method of claim 33, wherein the WGRS address is auniversal locational address (ULA).
 36. A Unified Geographic Database(UGD) comprising records for multiple entities, each entity recordincluding a World Geographic Referencing System (WGRS) domain-name, likehierarchical address associated with location-related information for anentity.
 37. The database of claim 36, wherein the WGRS address is auniversal locational address (ULA).
 38. The database of claim 36,wherein the WGRS address is a proprietary name address (ULA).
 39. Thedatabase of claim 38, wherein the PLA includes an entity name or anabbreviated version of an entity name.
 40. The database of claim 38,wherein the PLA includes a brand name or an abbreviated version of abrand name that serves as an identifier of the entity as one of theentity's branded products or services.
 41. The database of claim 36,wherein the location-related data includes static data.
 42. The databaseof claim 36, wherein the location-related data includes dynamic data.43. The database of claim 36, wherein the location-related data includesreal-time data.
 44. The database of claim 36, wherein thelocation-related data includes a link to location-related data for theentity located outside the record.
 45. The database of claim 36, whereinthe location-related data includes one or more generic categories thatrelate to the nature of the entity.
 46. A Location Name Server for usewith a client and a Unified Geographic Database (UGD), the UGD havingrecords for multiple entities, the records including World GeographicReferencing System (WGRS) domain-name, like hierarchical addressesassociated with location-related information for the entities, theLocation Name Server comprising a conversion engine for converting fromthe client a street address or latitude/longitude coordinates to a WGRSaddress for accessing an entity UGD record based on the WGRS address.47. The server of claim 46, wherein the server includes memory having aULA look-up table with ULAs associated with street addresses and/orlatitude/longitude coordinates.
 48. A Location Name Server for use witha client and a Unified Geographic Database (UGD), the UGD having recordsfor multiple entities, the entity records having proprietary locationaladdresses (PLAs) associated with location-related information for theentities, the Location Name Server comprising a conversion engine forconverting from the client a proprietary name to a PLA for accessing anentity UGD record based on the PLA.
 49. The server of claim 48, whereinthe server includes memory having a PLA look-up table with PLAsassociated with proprietary names for converting the proprietary namesto PLAs.
 50. A method of using a location name server with a client anda Unified Geographic Database (UGD), the UGD having records for multipleentities, the entity records having proprietary locational addresses(PLAs) associated with location-related information for the entities,the method comprising: receiving a proprietary name from the client;converting the proprietary name into a PLA; sending the proprietary nameto the UGD for accessing an entity UGD record based on the PLA.
 51. Themethod of claim 50, wherein converting includes determining the PLAbased on searching for the proprietary name in a PLA look-up table.